The current block is the child and the previous block the parent. If the parent changes in any way then this will cause a change in the previous block hash pointer of the child. So the change does not ripple back to the genesis block. However what this does do is that once a block has many generations following it then it makes it very difficult to change. So the genesis block as the first block is impossible to change because changing it would make it necessary to change the previous hash of every block that followed it.


Why does my wallet size increase over time?

The current wallet.dat file increases because you add new keys when you refill your keypool (get new addresses) or if you receive or send transactions. Mind that every wallet-relevant transaction is stored (together with some metadata) in your wallet.dat.


Proof of stake is a proposed alternative to proof of work designed to increase network security. It's not currently implemented in the main chain (and would likely require a hard fork to implement), but alt currency PPCoin features a hybrid proof-of-stake/proof-of-work system of sorts.

With proof of work, the likelihood of mining a block is dependent on the work done by the miner, e.g. the number of hashes checked for validity by a CPU, GPU, FPGA, or ASIC. As such, over time, the blocks are split across miners proportionally to their relative hashrates. With proof of stake, blocks are split relative to current wealth, so someone possessing 1% of the bitcoins currently in existence could "mine" 1% of the proof of stake blocks.

This proposed system has a few (theoretical) benefits relative to proof of work:

Reduced long-term transaction fees

When transaction fees form the majority of block rewards, with the current proof of work system, miners would be forced to require a "minimum" transaction fee if they wish to remain profitable, as they must utilize physical and costly resources (hardware, electricity, internet, etcetera) in order to mine blocks. Proof of stake has no such limitation, as solving blocks would require no physical resources whatsoever (apart from a computer running the Bitcoin software, which is essentially negligible).

Decreased likelihood of a 51% attack

In the current proof of work system, an attacker need merely obtain over half the current network hashing capacity for a short amount of time to perform a so-called "51% attack". With proof of stake, an attacker would need to obtain over half of the bitcoins in existence, a far more expensive and difficult feat. Moreover, performing a 51% attack and likely devaluing Bitcoin significantly wouldn't be all that appealing if you are so heavily vested into it.

However, this is debatable. If a single entity could obtain, even temporarily, loans or other borrowed capital comprising over half the network, they could perform a 51% attack with very little input resources, and might well have good incentive to do so. Just as centralized or leasable hashpower dramatically increases the risk of a 51% attack on a proof of work system, centralized or borrowable wealth dramatically increases the risk of a 51% attack on a proof of stake system.

Proof of stake was first formally proposed by forum user QuantumMechanic here. Two at least somewhat complete implementation specifications have been released, one by Meni Rosenfeld and one by Cunicula; both are explained in detail on the proof of stake wiki page. Both are hybrid proof-of-stake/proof-of-work implementations, meaning that 51% of the total wealth and 51% of the network hashpower would be required to create and maintain a fork. You can find the (unofficial) forum discussion thread here.


Do we still need SIGHASH_NOINPUT for Lightning Network?

The lightning network as is is working without SIGHASH_NOINPUT. Thus in its current form it is not needed.

However Christian Decker came up with the eltoo payment channel construction. In a nutshell this would get rid of the penalty based construction we use right now and reduce a lot of overhead for maintaining channel state as the state becomes symmetrical for all participants.

In particular multiparty channels and channel factories would become much easier.

The eltoo paper however really depends on SIGHASH_NOINPUT as the channel state is encoded as a "linked" list of update transactions which in case of protocol breach are skipped from the breaching point to the current channel state which requires SIGHASH_NOINPUT.

It is my understanding that essentially all lightning network developers agree that lightning network channels should eventually be constructed via eltoo.

You can read a summary of eltoo on my blog or you can read the original publication to learn more.


What if all transactions are off-chain in Bitcoin?

I agree that a future could emerge in which most payments will be handled offchain. Whenever you want to pay someone and it can't be done via lightning you could just open a payment channel for that amount and keep it open. I also assume cheating won't be too much of an issue and people have strong incentives to keep channels open as the bitcoin are much more liquid on there.
However channel openings and closing will still be a thing thus the bitcoin base layer won't become obsolete and still needs to be maintained. Also some rebalancing is not possible off-chain.
I think in the scenario the bitcoin base layer becomes the institution enforcing the rules of the Lightning Network but it will just be too expensive to do transactions regularly on the baselayer.


RSA accumulators are far harder to implement correctly
RSA accumulators need a trusted setup (someone, or multiple someones, must come up with a sufficiently large integer that is the product of 2 primes, and then throw those individual primes away). Bitcoin is generally designed to avoid trusted parties.
For a 128-bit security level, you need at least 3000 bits RSA moduli, meaning that a proof would be 3000 bits. That's only a win compared to Merkle paths for trees with more than 12 levels, which in the case of transactions in blocks, means over 4096 transaction. That isn't usually the case, and even when it is, it is only barely so.


Is it possible to determine BIP39 keys are related

BIP 39 is only a mnemonic standard, it is BIP 32 which describes how the derivation actually works.

Unless you have the master public key or the master private key, no, you cannot know whether two keys were derived from the same BIP 32 master private-public keypair.


Stratum protocol - problem with mining.submit method

The error is pretty self explanatory: you submitted a share that does not meet the requested difficulty. The pool requires that shares you submit meet a particular difficulty. If your shares do not meet that, then the pool will reject them. The shares that your software is sending to the pool do not meet the pool difficulty.

To fix this, either you are creating the submission incorrectly, or your miners are not mining at the correct difficulty.


The bitcoin address space seems to be closer to 2^40, not 2^160

No, 58^34 is greater than 2^160: http://www.wolframalpha.com/input/?i=2*160+%3E+58*34

Note, that the address also contains a checksum and a network id not carrying additional information. That's why the numbers are not equal.


Unable to receive/preview funds due to un-synced wallet

You will be able to see them as soon as you synch the block that contains the payment.


Bitcoin cash signraw "Input not found or already spent"


Why choose the longest chain before checking for double-spending?

If there is a double spend attempt, there is no way for a node to know "which chain (transaction) actually came first and is legitimate". Some nodes may hear about the 'legit' chain first, some may hear about the double-spend chain first.

So, if the rule states that nodes work to avoid reorgs in case of a double spend, then we would expect the network to split at the occurrence of a double spend. Consider: what happens if there is a double-spend attempt, and the first chain your node hears about is the one that is soon-to-be the shorter chain? You would be stuck on an orphan chain, while the rest of the network marches onward. This is obviously not good, as network consensus and reliability is important.

  c) For nodes that receive only one chain, accept it if it does not require a reorganization.

If the node only receives one chain, then it will never require a reorg. Only a node that receives an alternative, longer chain will reorg.

  ..accepting the longest chain blindly? Shouldn't we check the block contents from both chains before deciding which one to accept?

I would not say chains are accepted blindly, acceptance requires the chain to be valid according to all of the network's rules. Your node will check the contents of new blocks, but as I mentioned above, there is no way to reliably distinguish a 'legit' transaction from a 'double spend' transaction, at a network-consensus level.


HD wallets help avoid reusing addresses when receiving payments because you can generate a new address each time. HD wallets also make backup of many addresses much easier:

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

You are correct that when you send a payment from an HD wallet that needs to combine Bitcoin from several addresses (because no single address you control has sufficient Bitcoin to fund the payment by itself) previously unconnected addresses can become linked together.

There are multiple ways you can deal with this scenario to greatly improve privacy. Coin control and careful planning of payment sizing can minimize the frequency and privacy impact when this needs to happen. You can send Bitcoin from only one address when you desire the most privacy and combine Bitcoin from multiple addresses when privacy is less important to you.

Another solution would be this idea from Peter Todd:

"For me personally shapeshift adds a lot of value to Bitcoin, as it gives me much stronger privacy by using Monero as an anonymous intermediary point. Specifically, I buy Monero on shapeshift, then sell it to xmr.to, which in turn sends bitcoins to the Bitcoin address of my choice."

"https://www.reddit.com/r/Bitcoin/comments/3s085o/why_the_altcoin_takeover_scenario_has_become_a/cwt2prf"


How to read the transaction pages on blockchain.info?

Change for a transaction doesn't have to go back to the original address: part of it can be sent to the receiver, and the other part can go back to a new address. That way it's slightly harder to trace where the money went, as you don't know which part was the transfer and which part was the change.


How do bitcoin exchanges commit the limit/market orders?

In general, if an exchange wants to execute a buy or sell order without asking you, the relevant Bitcoins need to be held by an address that the exchange controls. When an order executes, and Bitcoins change hands, nothing changes on the blockchain. The only thing that changes is a record internal to the exchange. It's only when you withdraw the money from the exchange that anything changes on the blockchain.


If the economy was based on bitcoin, how would someone go about getting a loan?

Loans are possible in a deflationary environment.  Currently bitcoins is too volatile (which has nothing to do with deflation) to make lending viable.  For the purpose of answering the question I will assume that in the future volatility is either low or easily hedges.

The interest in a loan comes from 4 components:

Opportunity Cost.  Instead of giving you a loan I could do something else productive with the money.  If I could get a 10% ROI on my money by installing a new air-conditioner that will factor into the interest I change.  It would be a loss to loan money to you at less than 10% (after adjusting for the other risks) as I would "earn" more by taking the 10% ROI.
Inflation risk.  If money is worth 5% less in one year I will want to be paid 5% more even on a no risk no profit loan.  Thus inflation contributes to the overall interest charged.  Deflation would subtract from the overall interest charged.
Default risk.  If you don't pay me I lose money.  In the long run I need to collect interest equivalent to % of amount loaned that is lost due to defaults.  If I project I will lose on average 10% of amount loaned and charge 11% interest then I would break even.  Note: real world calculations are more complex because one may collect some revenue even from loans that default and may receive collateral, or sell defaulted loan for some recovery.  Still default risk needs to be included in the price of the loan.
Delayed Consumption.  By giving you a loan (even if priced to exactly break even) I am delaying my ability to use my money today.  I can't use it until repaid thus I will charge a premium for the time I lose waiting for repayment (sometimes called time value).  Thus even if all other costs/risks are 0% there will be some interest charged otherwise I might as well just keep the money in a can.

Interest is the "cost" of money.  Of the four components that contribute to that cost only one of them is related to inflation/deflation.  If in the long term all other factor were equal (which is unlikely), the USD had 3% inflation rate, and BTC had a 2% deflation rate one would be expect interest rates in BTC to be ~5% lower.


Does the bitcoin testnet3 network support Segwit and OP_CSV?

Yes, testnet3 supports SegWit as of block 834624.
Yes, testnet3 supports both OP_CSV and OP_CLTV.

You might also be interested to know that there is a segnet test network on another port number. See https://bitcointalk.org/index.php?topic=1453392.0 for more details.


How to get the list of transactions of input/outputs for a bitcoin address in JSON format?

As answered above you can use blockchain.info for extracting the results. Here I would like to add to the solution provided by m1xolyd1an, his code works fine but it extracts only latest 50 results/transactions made by the address that you are trying to retrieve the data for.

In order to extract the complete details of the transaction right from the beginning, some minor tweaks have to be made to the code. Below is my solution

<?php
$address = $_POST['Address'];
$url = "https://blockchain.info/address/".$address."?format=json&offset=0";
$json = json_decode(file_get_contents($url), true);

$totalTxs = $json["n_tx"];
echo "Total transaction : $totalTxs";
for($ex=0;$ex<$totalTxs;$ex+=50){
//$address = "1HB5XMLmzFVj8ALj6mfBsbifRoD4miY36v";
$url = "https://blockchain.info/address/".$address."?format=json&offset=$ex";
$json = json_decode(file_get_contents($url), true);

//total transactions
$totalTxs = $json["n_tx"];
//final balance
$balanceSatoshis = $json["final_balance"];
$balanceBitcoins = $balanceSatoshis / 100000000;
$balanceBitcoins = number_format($balanceBitcoins, 8);

//loop through each transaction and display all inputs and outs
for($i=0;$i<50;$i++){

echo "

";
echo "HASH OF TX:
";
$hash=$json["txs"][$i]["hash"];
echo "&nbsp;".$hash;

echo "	SENT FROM:
";
$n_inputs = count($json["txs"][$i]["inputs"]);

for($ii = 0; $ii < $n_inputs; $ii++){
    $inValue = $json["txs"][$i]["inputs"][$ii]["prev_out"]["value"];
    $inValueCalc = $inValue / 100000000;
    $inAddy = $json["txs"][$i]["inputs"][$ii]["prev_out"]["addr"];
    echo "&nbsp;". rtrim(number_format($inValueCalc, 8), '0') ."&nbsp;". $inAddy ."&nbsp;";
    echo "
";
    }

echo "	SENT TO:
";
$n_outputs = count($json["txs"][$i]["out"]);

for($io = 0; $io < $n_outputs; $io++){
    $outValue = $json["txs"][$i]["out"][$io]["value"];
    $outValueCalc = $outValue / 100000000;
    $outAddy = $json["txs"][$i]["out"][$io]["addr"];
    echo "&nbsp;". rtrim(number_format($outValueCalc, 8), '0') ."&nbsp;". $outAddy ."&nbsp;";
    echo "
";
    }
echo "

";
}
}
?>


Can a client leave its mark on the blockchain?

The OP_RETURN feature can be used to accompany a transaction with arbitrary data.  A standard transaction can contain an OP_RETURN output with up to 80 bytes of data (40 bytes prior to Bitcoin Core 0.11).

You could have a client that includes an OP_RETURN output with every transaction, containing whatever meta data is desired (client software version, info about client settings, friendly greetings, Bible verses, etc).

However, since this would make each transaction larger, the users of this client software would on average pay higher transaction fees (depending on how often the extra data pushes your transaction past a 1 KB boundary, since the fee is per KB).  Also, since every full node has to store the extra data forever, some people might consider this feature to be "unfriendly" to the block chain, even though it is legal in the protocol.

Given these tradeoffs, one would probably not implement such a feature without a pretty compelling reason to do so, beyond simple curiosity.


Synchronizing with network – What does it mean?

It's most likely you're using the client from bitcoin.org.

Synchronizing with the network refers to the download and verification of the blocks in the block chain, which is the transaction history of Bitcoin. The block chain is the record of who spent what and when they spent it, and who owns what now.

Currently, the bitcoin.org client downloads the entire block chain on installation, which is somewhere around 3GB of data. As it downloads each block, it confirms each transaction, which is a disk-intensive activity. Unless you have high spec hardware, expect it to take many hours, possibly even days.

Version 0.8 of the bitcoin.org client alters the synchronization process, which heavily reduces the time required to get the client functional. The process is faster through being less disk intensive.

Alternative clients are also available, such as Armory or Electrum, which don't use the same synchronization process. Electrum doesn't download the block chain, and the features list for Armory says it doesn't need the block chain.


What's a good algorithm for reducing Transaction fees?

https://en.bitcoin.it/wiki/Transaction_fees
Those are rules about calculating fees.

Considering algorithms, i think you should check all possiblities (brute-force) or it could be also some kind of knapsack problem.


BTC mining is not a real option anymore for home miners. It's not profitable as it was before. The only way to be profitable with BTC mining these days is custom made computers that are made for BTC mining.

The most people with a normal or gaming pc lose money instead of making profit when mining BTC.


When does Ardor smart contracts come into effect and how does it work compared to Ethereum, EOS, and Lisk?

First off, Lisk doesn't have full turing-complete smart contracts so there isn't much of a comparison on that front.

Key shortcomings of existing frameworks like Ethereum can be summarized by five challenges:

Contract life cycle management – Find a security bug? Good luck re-deploying.
Transaction fees – Want to use my service? First, you’ll have to buy some “gas,” in the form of cryptocurrency, to use to sponsor your transaction fees – no matter what service you are trying to use. This means there will be some crypto-tax implications for your end users.
Integration with External Services – Want to leverage an existing database? Contracts are part of the blockchain consensus, which means they cannot interact with external systems like a cloud service or game engine.
New coding languages – Solidity on Ethereum and RIDE on Waves are complex and relatively unknown to most experienced software developers, creating a substantial barrier to entry. There are also fewer reliable libraries and tools to leverage in the development process.
Privacy – Looking to create verifiably replicable random numbers and store secret information? It’s either not possible, or incredibly complex.

This combination of factors has already led to numerous instances of user funds being locked up because of vulnerable smart contracts such as in the instance of the DAO and the Paritytech Wallet Freeze.

Lightweight Contracts on the Ardor platform offer a comprehensive solution to these issues. These new “stateless” contracts are written in Java, allowing developers to automate business processes on the blockchain in a comfortable coding language, while leveraging 250+ APIs to launch digital assets, marketplaces, voting systems, cloud storage solutions, messaging applications, and more. Reflecting on the issues of first-generation smart contracts, lightweight contracts address those issues of contract lifecycle management, transaction fees, integration with external systems, and random number generation as follows:

Two Step Deployment – Contract code is deployed to child chains, such as Ignis, as a cloud data item, which stores a signed and time-stamped copy of the executable code on the blockchain, and a contract reference, which serves as a pointer from a specific contract runner account to the contract code, while defining setup parameters for the contract. This level of indirection simplifies contract upgrades- all developers need to do is deploy a new version of the contract and then gradually update existing references to it.
External Integrations – Interfacing with external systems, like cloud services and game engines, is enabled and encouraged.
Privacy – Random numbers can be generated in a reproducible method and secret information can be saved privately.

Lightweight Contracts are deployed on individual nodes, with optional verification and approval nodes reproducing results to ensure transparency and fairness. This provides a significant level of confidence in the output transactions of Lightweight Contracts, but what happens if a user sends a transaction to the node running a “contract runner” – and the node fails to execute the contract?

The trust problem lies at the core of all systems looking to deploy smart contracts on individual nodes. After several months of research, the developers at Jelurida finally found their solution by repurposing a lesser-known feature deployed on NXT back in 2015, known as phased transactions by hashed secrets. The basic idea is that funds sent by the user are not credited to the contract runner account. Instead, funds are held in a temporary escrow by the blockchain itself until the contract runner executes the contract and the user, after validating the resulting transaction, reveals the secret. As a result, the user transaction and the contract reply transactions are either both approved or both ignored and funds are unable to be permanently locked or stolen.

Documentation for the Ardor platform and its lightweight contracts can be found on the Ardor Learning Hub at ardordocs.jelurida.com. This response was modified from an article on CCN: https://www.ccn.com/ardor-lightweight-contracts-since-existing-smart-contracts-are-not-so-smart/


I'm trying to create a new kind of escrow with bitcoin, not sure if it's possible

Partial answer (not a new solution - I merely adapted the micropayment channel protocol):
if you allow for public key exchange, one solution seems to me to be:

t1: source funds an address A controlled by source and escrow
t2:
source partially signs transaction T spending A to destination. Then
she sends this partially signed transaction to escrow.

it is now up to escrow to sign and broadcast T so that destination receives the fund. Escrow cannot spend the funds differently (i.e. steal) as it would require source to cosign.

(Problem: Escrow could decide to not sign and "block the funds" (that s why Refund transactions are included in payment channels). Solved by having Escrow partially sign and send to source a transaction R sending hte funds from A back to source at t0. It s now up to source to sends herself the funds from A back. Is this an issue? Not really if you have transaction R be "timelocked")

It seems harder to find a solution without public key exchange... but it is a bit strange to forbid public key exchange.


Do any Virtual Currencies use coins that have an expiration date?

It hasn't been tried yet

At this point to the best of my knowledge there is no crypto currency that uses either expiration of transaction outputs or expiration of addresses. Therefore there are no experimental results available to observe expiration's effect on velocity.

It wouldn't affect velocity

However, one might argue that any sensible period of time (at least five years) would not have a significant effect on the velocity of the money: Savings would just be moved and the transaction fee would not pertain to a significant amount of loss. There'd be a jackpot every once in a while in the mining rewards, creating peak hash rates, and sudden liquidity spikes if the miners sell their rewards directly. Compared to the velocity generated by the majority of the user population that should be negligible though.

A smaller period of time would turn into a saving fee per address, as you'd be forced to pay at least one transaction per address every period of time. This would disadvantage smaller bitcoin holders compared to people that have larger funds in fewer addresses.

Freicoin implements demurrage

The closest that I could come up with is Freicoin, which implements a demurrage of about 5% per annum. It is implemented in such a way that every time a block is mined a tiny fraction of your savings will be added to the mining reward, so that you will lose about 5% per year.

Demurrage slowly drains lost funds

While the demurrage is mainly implemented in order to discourage hording, stabilize the mining reward, and increase the velocity of money, it will also very slowly drain lost funds back into the mining reward. Assuming the target block interval were maintained, in 20 years about 64% of lost funds would be returned into the market. After 50 years more than 92% of lost funds would be recycled.


Why does an exchange of bitcoin transaction not need to be over a secure connection?

Conventional banking relies on you and your bank both knowing some sort of secret, like a PIN or your mother's maiden name. This requires encryption, because otherwise someone listening in on the connection can capture the information and impersonate you.

Bitcoin uses only public key cryptography to identify accounts. It is possible to prove that the creator of a transaction had access to a private key without revealing what that private key is. See also How does the ECDSA verification algorithm work during transaction?

Also, although Bitcoin connections are usually not encrypted, there are circumstances where they probably should be, like if you want to make sure that the administrator of the local network doesn't know which Bitcoins you're spending.


How difficulty increases to get the lucky hash in blockchain?

The Bitcoin algorithm is written to aim for 2,016 blocks being mined roughly every 2 weeks (which works out to ~1 block every 10 minutes on average). After every 2,016 blocks, the network will adjust the difficulty based on how long those previous 2,016 blocks took to mine: if it took longer than 2 weeks, the difficulty is decreased; if it took less than 2 weeks, the difficulty is increased.
For the exact calculations and more information: https://en.bitcoin.it/wiki/Difficulty


How can I find a hash with leading zeros

You're missing multiple parts here. If that's your complete code, you don't seem to be adding a nonce to your preimage at all. You will need to generate a nonce, add it to the preimage, and test the corresponding digest against your acceptance criteria. To that end, you probably want to use a while loop that continues rolling random nonces and testing digests until one has the correct prefix. In the success case, it should output the relevant nonce.

You will also need to make sure that you use the same method of combining the nonce and your name as the exercise's test framework.


Can a bitcoin block reward be paid to a multisig address if the transaction is included in the block?

Sure. The miner decides what the payout transaction looks like. It can be paid to any address using any valid type of transaction.

What's specifically checked by the network on coinbase transactions is the absence of output reference in the input, the coinbase position in the block (first) and the reward amount. The output script can be any standard script.

As a matter of fact, rewards used to be paid as pay-to-pubkey transactions. Nowadays, most pools have transitioned to using pay-to-pubkey-hash transactions.


Could Taproot create larger security risks or even hinder future protocol adjustments re Quantum threats?

This particular response is approximately tripe. Building on Pieter Wullie's comment.

  find an appropriate post-quantum DSA

and

  it might push the the time to make Bitcoin quantum-secure from 5-10 to 10-20 years, as much more research is needed.

We really know what to do to make Bitcoin Quantum safe, there's been methods for doing hash based cryptography in varying forms since 1979, which predates even Schnorr in 1991. Adding a new signature type to Bitcoin can be done with a soft fork, even though the specifics of how this would work (they would likely be a merkle tree of public keys).

I personally wrote a patch for adding OP_LAMPORTVERIFY as a project while bored on a plane in 2015, other than coming up with something sensible for the formats and desperately trying to convince people not to re-use addresses (for real this time!), it's engineering that can be done on a short international flight.

  With taproot activated, we also need to solve (3). If we solve (1) and (3) together, this may take too long to achieve (2). That's the risk we take by activating taproot now.

The two are basically orthogonal, there's no difference between migrating between outputs stored with taproot and those using raw ECDSA. The existence of taproot doesn't make this any more or less difficult functionally.

If any quantum computing was a significant threat (ie, wasn't just theoretical or slower than classical computing), we would have a lot more to worry about than just Bitcoin regardless.


Is there any exchange website that directly converts to a specific currency once a cryptocurrent payment is received?

What you're looking for is a payment gateway service, and if they take settlement in fiat such as USD or Euro.

It appears Coinpayments.net works on Woocommerce and allows you to withdraw in fiat pairs. You could also look into GloBee, BitPay, Paybear and Coinbase payments, and compare what they offer to see if they suite your needs.


Bitcoin full node installation on Raspberry Pi3 not working

Looks like libboost is not installed?

Try:

apt install libboost-all-dev -y

Then rebuild:

./autogen.sh; ./configure; make


You're looking for regtest. It lets you generate as many blocks as you want on a private network.


Why does the order in which the transactions occur matter when we reconstruct ownership information?

I was wondering why the order in which the transactions occur matters when we reconstruct ownership information. Can't we just aggregate all the input and output for each account to calculate how much it owns?

There are no accounts on Bitcoin, but even if there were accounts, how would you deal with the case where the sum of the transactions exceeds the funds necessary for all of them to be valid?  Transaction order is necessary to deal with that case.  Here's an example:

Mallory receives 1 BTC to her account
Transaction A spends 0.5 BTC to Alice from Mallory's account
Transaction B spends 0.5 BTC to Bob from Mallory's account
Transaction C spends 0.5 BTC to Charlie from Mallory's account

Assuming negative balances are forbidden, the order of these transactions determines who gets paid.

Because transaction order matters, and for other reasons, Bitcoin doesn't have accounts.  Each time you receive funds, it's paid to an output that's uniquely identifiable.  That is, it may have the same spending condition (e.g. address) as other outputs you've received, but each output can be uniquely identified by the transaction it appears in (txid) and its sequence in the series of outputs in that transaction (output index number, or output vector (vout)).

When you spend funds, you create an input that uses that unique identifier (called an outpoint) to references the output you're spending.  Bitcoin only allows you to spend an output once within a block chain (an ordered list of transactions), so you have to spend all of the value of that output or you lose the value you don't spend.


How is the prioritization of Bitcoin Transactions done as of today?

The (close-to¹) highest block reward is achieved by including the transactions with the highest fee per weight. Deviating from that, miners are free to include any valid transactions at whim. They may for example choose to include their own transactions, transactions for their business partners, or transactions subsidized by out-of-band payments over other that would gain them higher revenue.

While a miner could still choose to select by coin-age-priority, this would neither be economically rational, nor supported by default by the latest versions of Bitcoin Core. Coin-age-priority was deprecated in Bitcoin Core 0.12.0.

¹ It's fathomable that a case could be constructed where selecting strictly the transactions with the highest fee rate would leave the block not completely full and selecting other transactions instead would increase the absolute revenue.


how do miners verify transaction without identifying sender and receiver?

by keeping public keys anonymous.

The whitepaper is referring to how, by default, it is not know which human or organisation controls a public key. ---The public key itself can be recovered from the signature on a Bitcoin transaction--- The public key is included as part of the scriptSig on a transaction input, and then hashed and validated against the public key used to create the address.

Since a signature can only be produced by the corresponding private key, you can validate that it is the correct key for the given address.

Thus, although you can see the amounts being moved around, you don't know who is spending them, or where they are going (without doing off chain analysis).

  By keeping public keys anonymous how miners can verify that sender has enough money

Now that we've established that the key itself is available, miners validate that the amounts are correct by referencing the chain of inputs. Each input in a transaction refers to a specific output created in the past. When validating, the node will look up all of the previous transactions referenced, add up all of their output values, and then check the current transaction's outputs. If the outputs created by the transaction are less than or equal to the input sum, it is valid.

In practice, outputs are less than the input currently, since 0 fee transactions are no longer allowed (they can still be mined, but you will find it quite difficult to broadcast them). The difference between the inputs and the outputs is claimed by the miner as the transaction fee.

The complete signature and address verification process involves:

Validating the signature over the transaction data
Hashing the public key from the scriptSig using HASH_160, and comparing it to the hash embedded in the address

This verifies that:

The transaction itself is signed
The public key matches the public key inside the address (by checking that the hashes are equal)


Yes and no: this is a presentation from 2015, and you are referencing a section which Pieter described as "assume we can redesign bitcoin". So bitcoin hasn't been redesigned, and not everything has been implemented as described in 6:20.

How it is handled today is part of a discussion with Andrew in bitcointalk (read down to page end). Older nodes don't get to see the witness data. They get just tx data, in an "anyone can spend" way, so it is recognized as valid tx by older nodes. Newer nodes get the witness data (of course).

  Am i right saying that signatures for segwit outputs will never be
  relayed to old clients?

yes.


There is a testnet for this sort of thing so you don't lose any money playing around.
See https://en.bitcoin.it/wiki/Testnet and
http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

After that you'll have to decide what approach you want to take. Are you integrating bitcoin into a larger project, or do you want to play with the internals? You can run a live bitcoind node and interact with the network through RPC commands if you just want to integrate it as a payment method. See https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) for whats available.

This won't get you into the nitty gritty of the protocol though. For that the best place to go would be bitcoinj. https://code.google.com/p/bitcoinj/

I would also suggest looking into Armory's software if the purpose is interacting with wallets in an online environment.


Should a user be notified about "last modified" time of bitcoin.conf while the bitcoin core wallet is loading?

No.
If your machine is compromised you can't trust last modified timestamps.
One of the obstacles to Bitcoin adoption is complexity. Developers should keep the user interface as simple and clear as possible. 99.9% of users wouldn't understand the information or how to use it.
A better approach to detecting malicious changes to a configuration file might be to encrypt the configuration file with the wallet password or to store a checksum of the config file in the encrypted wallet file and only alert the user when configuration changes are detected that were not made via the wallet software itself.  But any message should carefully and clearly explain what the situation is without confusing new inexperienced users.
I'm not sure how useful this is since if your wallet config has been maliciously altered the whole computer is untrustworthy.


A simple google search does the trick.

There are mutiple APIs from major crypto currency exchanges:

CoinBase API
Kraken API


Must I have an account with every gateway I use as an issuer?

Where can I find the address?

The address you need to trust to hold Bitstamp issued currencies is available from the Bitstamp website, but as you noted, you must be logged in to see the relevant page.

You can also find the address at https://www.bitstamp.net/ripple.txt under the [accounts] key. The ripple.txt file is documented here: https://ripple.com/wiki/Ripple.txt

Do I need an account?

You do not need to have an account with Bitsamp to be able to hold Bitstamp-issued assets. All you need is to trust their address. You can then buy Bitstamp-issued BTC, or USD or EUR or whatever else purely on the Ripple network.

Of course, having a Bitstamp account will allow you to redeem those IOUs through Bitstamp. Without such an account, you can still trade them on the Ripple network for either XRP or other assets, likely issued by another gateway.

You may find this primer to be of help: https://ripple.com/guide-to-ripple-gateways/


Who decides whether a submitted share leads to a valid block or not?

Yes, shares are there to provide to the pool operator that you are working with the pool. Because you are actually hashing data and providing valid hashes of the data the pool sent, it proves you are working with them, meaning you deserve some of the sweet BTC reward when someone finds the actual answer.


Why is OP_CHECKLOCKTIMEVERIFY disabled by maximum sequence number?

the purpose of OP_CHECKLOCKTIMEVERIFY is kind of the opposite to the purpose of tx.nLockTime. tx.nLockTime prevents transactions with future dates from entering the blockchain, whereas OP_CHECKLOCKTIMEVERIFY enables someone to freeze funds so that they can only be spent after a given timestamp or block height.

tx.nLockTime

tx.nLockTime is validated by function IsFinalTx() in src/main.cpp:

bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime)
{
    if (tx.nLockTime == 0)
        return true;
    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;
    BOOST_FOREACH(const CTxIn& txin, tx.vin)
        if (!txin.IsFinal())
            return false;
    return true;
}

where txin.IsFinal() is in src/primitives/transaction.h:

bool IsFinal() const
{
    return (nSequence == std::numeric_limits<uint32_t>::max());
}

If the tx locktime is below the threshold then it is treated as a block height and if it is above the threshold then it is treated as a timestamp. Either way, the transaction locktime value must be smaller than the relevant constraint. If it is larger then miners must wait before including the transaction in a block.

The only way to bypass this transaction locktime constraint is to disable the transaction locktime completely by setting all txin sequence numbers to maxint. When this is done then miners will include the transaction straight away, even if the locktime has not yet been reached.

The idea with the transaction locktime is that before the transaction is locked (ie before the block height or timestamp catch up with tx locktime), someone can make amendments to the transaction. Each time they make a change then they must increment the sequence number to let miners know which amendment comes after another.

One use case for this might be a digital will. If you wanted to pass your money on to someone else specifically in the event of your death then you could create a transaction with a locktime of one year from now and then give it to a few friends. In the event of your death they can broadcast this transaction on the network after one year and the funds will be sent accordingly. Broadcasting the transaction before this time period of one year would not enable them to receive funds, since miners will ignore the transaction until the time period becomes valid (and obviously the friends cannot alter the functionality of this transaction since it is signed by your private key which you never disclose).

If you don't die then you can spend the funds to a different address of your own choosing by broadcasting a different transaction on the network. Your friends will then not be able to use the original transaction you gave them since this would be a doublespend, which the miners do not allow. For the transaction which you broadcast to cancel the will you would alter the locktime to make it sooner, and increment the sequence number. Alternatively you could set the locktime to 0 or set the sequence number to maxint to spend straight away.

OP_CHECKLOCKTIMEVERIFY

OP_CHECKLOCKTIMEVERIFY has a very different use. It is validated in function EvalScript() in src/script/interpreter.cpp:

            case OP_CHECKLOCKTIMEVERIFY:
            {
                if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) {
                    // not enabled; treat as a NOP2
                    if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
                        return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
                    }
                    break;
                }

                if (stack.size() < 1)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

                // Note that elsewhere numeric opcodes are limited to
                // operands in the range -2**31+1 to 2**31-1, however it is
                // legal for opcodes to produce results exceeding that
                // range. This limitation is implemented by CScriptNum's
                // default 4-byte limit.
                //
                // If we kept to that limit we'd have a year 2038 problem,
                // even though the nLockTime field in transactions
                // themselves is uint32 which only becomes meaningless
                // after the year 2106.
                //
                // Thus as a special case we tell CScriptNum to accept up
                // to 5-byte bignums, which are good until 2**39-1, well
                // beyond the 2**32-1 limit of the nLockTime field itself.
                const CScriptNum nLockTime(stacktop(-1), fRequireMinimal, 5);

                // In the rare event that the argument may be < 0 due to
                // some arithmetic being done first, you can always use
                // 0 MAX CHECKLOCKTIMEVERIFY.
                if (nLockTime < 0)
                    return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);

                // Actually compare the specified lock time with the transaction.
                if (!checker.CheckLockTime(nLockTime))
                    return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

                break;
            }

which relies on function CheckLockTime() in the same file:

bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const
{
    // There are two kinds of nLockTime: lock-by-blockheight
    // and lock-by-blocktime, distinguished by whether
    // nLockTime < LOCKTIME_THRESHOLD.
    //
    // We want to compare apples to apples, so fail the script
    // unless the type of nLockTime being tested is the same as
    // the nLockTime in the transaction.
    if (!(
        (txTo->nLockTime <  LOCKTIME_THRESHOLD && nLockTime <  LOCKTIME_THRESHOLD) ||
        (txTo->nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
    ))
        return false;

    // Now that we know we're comparing apples-to-apples, the
    // comparison is a simple numeric one.
    if (nLockTime > (int64_t)txTo->nLockTime)
        return false;

    // Finally the nLockTime feature can be disabled and thus
    // CHECKLOCKTIMEVERIFY bypassed if every txin has been
    // finalized by setting nSequence to maxint. The
    // transaction would be allowed into the blockchain, making
    // the opcode ineffective.
    //
    // Testing if this vin is not final is sufficient to
    // prevent this condition. Alternatively we could test all
    // inputs, but testing just this input minimizes the data
    // required to prove correct CHECKLOCKTIMEVERIFY execution.
    if (txTo->vin[nIn].IsFinal())
        return false;

    return true;
}

Here the transaction locktime is compared to a value on the stack. To validate successfully, both must be the same side of the theshold (ie both must be interpreted as a block height, or both as a timestamp), and the script will only validate if the stack value is lower than the tx locktime. Or to put it another way, the script will only validate if the transaction locktime has passed the stack value.

Whereas IsFinalTx() prevents transactions with locktimes in the future from being included into the blockchain in the present, OP_CHECKLOCKTIMEVERIFY freezes funds in the blockchain so that they can only be spent after a specified time in the future.

Note that the stack value used for comparison is most useful when placed in the scriptPubKey. The locktime used for comparison against the stack value is that of the signing transaction. This forces the spender to wait for the block or timestamp in order to spend the funds.

As previously discussed, IsFinalTx() does allow transactions with locktimes above the current block height or timestamp to be mined - providing the sequence number is maxxed out, thus disabling the tx locktime. Submitting such a transaction with a maxxed out sequence number would be a sneaky way for the recipient to spend the funds earlier than the time specified by the sender in the txout script. So, to prevent the OP_CHECKLOCKTIMEVERIFY criteria from being bypassed, the script validation must fail when the tx locktime is disabled by the sequence number.


Minimum funds required in a channel in Lightning?

Testing further this, I found an answer for it: with current settings for lnd, one cannot transfer an amount such that leaves one of the sides with less that 1% of the channel capacity. This is most likely to prevent that one side to try to commit to an old state, since the punishment would be low.

For example, in the above case, if the channel capacity is 16777215, and the local_balance is 370557, then the maximum amount possible to transfer is 202742 because 370557-202742 ≃ 0.01*16777215 (it is not exactly 1%, probably due to fees that need to be accounted for).

I double tested this using a channel of capacity 7310000, and having as local_balance 4294965, and again my maximum possible value to transfer is 73143 ≃ 0.01*7310000 (again, not exactly 1% due to fees not accounted for in --amt).

As for the extra value, one would think it is fee_per_weight*172 + feerate*amt (fee per millionths transferred) in the case of the last hop, while they add up in previous hops. But this would mean a higher difference than 143 mSat, or 42mSat, as calculated in the examples above. I am not entirely sure how this difference not to be exactly 1% derives.

It has to do with the overflow bandwidth (the bandwidth of the channel that is currently being used for other unfinished routes). But still this does not match the numbers exactly. However, just a difference of a hundred satoshis is nothing but a fraction of a cent, so it is not a huge value. Nevertheless, I can't put my finger on the exact calculation...


Is it logical to use “Proof-of-Authority” for a “public” blockchain?

What is the reason? And Is it logical to use "Proof-of-Authority" for a "public" blockchain, in sense of keeping decentralization?

Proof of Authority is, by definition, centralised. If the authority nodes go rogue, or fail to reach consensus, the network is useless.

You could use it in public networks (some of the ethereum testnets are PoA), but it would not be a decentralized network. The value of a PoA mainnet would have to come from some benefit of its centralization, and a very high level of trust in the trusted authorities.


Your question shows that you're quite new to Bitcoin in general. I would advise you to do a little light reading about it to understand what bitcoin exactly is. Regardless..

  I get my bitcoin address from freebitco.in . So how can I login into my wallet to know about my bitcoins?

If you acquired your wallet from Freebitco.in, you were redirected to Blockchain.info, you can log in there to check your balance. You will only have balance there if you withdrew coins from Freebitco.in in the first place. Otherwise, log into Freebitco.in and withdraw your coins.

Blockchain.info is a web wallet, you'll find all the information you need about it on their website.

  How to convert bitcoins into dollars and send it in to my prepaid debit mastercard?

You will first need to sell your coins for fiat currency. There are literally hundreds of online exchanges, or people you could find locally to sell to on Localbitcoins. Here's a nice guide to get you started.

After you've read the guide, signed up for an exchange, and sold your coins, you can have them transfered to your bank account and use the money with your prepaid card.

Congratulations on starting with Bitcoin, I would recommend you not to cash out, and instead of converting your coins to fiat, try finding places where you can spend your bitcoin instead.


understanding timestamp from blockexplorer.com

In the network protocol, times are represented as Unix timestamps stored as unsigned 32-bit integers.

  is this time converted to 32bit hex for hash calculation, if so how ?

Bitcoin uses a binary protocol. Nothing is hex. When viewing the binary data, your tools may display the data in hex, but you can't directly use these hex characters for hashing, etc.


How to recover access to funds with blockchain.info passphrase

The answer is yes, I can access my funds using only my pass phrase.

Mycelium, for example, when installed, comes up and asks if I want to restore a wallet from a 12-word passphrase, which is what blockchain.info created.

It then found my funds and will allow me to send / receive.

I have since learned that the pass phrase is just used to generate the private key using the SHA-256 hash algorithm.


Meaning of this part of the Bitcoin Ticker Display?

That’s the market depth and it’s not related to bitcoin, any exchange of any asset provides this information. One way to interpret it is if someone sent a big market sell order of 22.542 BTC to this exchange, the price would drop to $52554.


At the moment SegWit2x forks, will mining be way easier?

No, it will not be easier. The "difficulty" of mining is determined by the difficulty (the value). The difficulty only adjust itself every 2016 blocks, so when the Segwit2x fork happens, the difficulty will not adjust until 1152 after the fork happens. So the difficulty will not change at the time of the fork for either chain (barring any difficulty adjustment thing that segwit2x decides to implement in the future) so it will be equally difficult to mine on both chains and thus not easier at all.

When the difficulty adjusts, it can only adjust by a factor of 4 at most, so only down to a difficulty 1/4th that of the difficulty at the time of fork. This means that it won't be possible to CPU or GPU mine either chain for a while as the difficulty needs to adjust down a lot.


How can one gauge the reliability, customer service, and transparency of bitcoin exchanges?

I totally agree that Bitcoin feels like the wild west, with people selling snake oil left and right.  It is early days, and that's how it works. If you want to be a pioneer, you will get arrows in your back. Right now, it's gambling, even more risky than gambling on the Stock Market.

If you're not comfortable with that, then wait. Down the road, there will be an influx of reputable exchanges. Right now, a "good" exchange won't make any more money than a fly-by-night exchange. But over time, the average reputation will increase.

The Internet worked the same way. Every Newspaper had an article on "Is the Internet a fad?" and warned "never use your credit card on the Internet". (Of course, kids these days don't even know what a newspaper is.)

  How can one gauge the reliability, customer service, and transparency of Banks or Retailers?

Think of how many reputable retailers had their credit card database stolen in the last 6 months. Think of how many banks went out of business without warning in 2008.

People are reporting on bitcoin exchanges that loose a few million, but nobody reports when a grocery store goes under and looses a few million.


The difficulty of the network adjusts in proportion to the hash rate, so that on average a block is found every 10 minutes. Of course, it's still a random process, so sometimes blocks are much shorter and sometimes they're much further apart.

As a result, if more hash power gets added to the network, the difficulty has to go up to compensate. Otherwise doubling the hashrate would result in one block per 5 minutes instead of per 10 minutes.

I don't understand where you think there is a contradiction, but feel free to clarify.


Noob: new to bitcoin, bitcoind will not run on Windows 10

You can run bitcoind.exe on windows if you leave off the -daemon flag, as the error message says. Then it will run in the command prompt window or whatever you are running it with. While it's running, you can interact with it using bitcoin-cli.exe in a separate command prompt window.

No, you can't run bitcoind and bitcoin-qt at the same time if they're using the same data/wallet directory, correct. But that's not the cause of the error here.


Are there any web wallets around with open APIs?

Yes, block.io is a good alternative with full wallet functions. No requirement for NPM or a VPS.


What if the bitcoin blockchain grows to the point it cannot be decentralized anymore?

How Bitcoin will scale into the future is a topic of much debate.  I will try to steer clear of too much opinion, and just give you the basic factors at play.

First, understand that there are different types of nodes on the Bitcoin network.  There are nodes that mine, there are nodes that keep full copies of the blockchain, and there are thin client nodes that only store the information required to maintain a single wallet.

The thin clients are what make up the vast majority of network participants, since this is what a normal user of the Bitcoin network will be running.  Since they don't store the blockchain, they don't care how much it grows.  The other two types of nodes are the ones where we are concerned with centralization.  They are what really represent the infrastructure of the system.

First, there are "full nodes", which keep full copies of the blockchain on hand.  These nodes provide requesting clients with historical blocks and transactions stored in their databases.  They also relay current transactions and blocks to other nodes, and verify the validity before passing the data on to other peers.  This provides the "plumbing" of the network and a first line of defense against malicious network participants.  It should be stated that there is no direct financial incentive for running a full node, yet it does require you to store the full blockchain (although some pruning is okay).

Second, there are mining nodes.  As the network has evolved from the specs laid out in the original whitepaper, mining nodes have become hyper-specialized.  Where at first, all full nodes had the option of mining, nowadays nearly all mining is done by mining pools.  These pools run their own networks of participants, and those participants only deal with hashing blocks they receive from the hub of the mining pool.  The nodes actually doing the mining are not running full nodes, but are relying on the mining hub to run full nodes and participate in the Bitcoin network.  Although the miners, themselves, can be very decentralized, there is already a certain degree of centralization of mining pool operators.  However, this is not due to the size of the blockchain, which is a negligible cost to a mining pool.

So, as the blockchain grows, it makes it less and less feasible to run a full node, yet this is not a problem for mining nodes and pools.  Full nodes are not paid for their service, so it becomes harder to justify running one if the data storage becomes expensive.  Luckily, data storage costs trend downward at a geometric pace, while the blockchain grows linearly (currently ~1MB/10min).  This means it is still feasible to run a full node for the foreseeable future.

I should also note that although there isn't a direct financial incentive for running a full node, there are several indirect incentives.  Running a full node allows a network participant to operate in a trustless manner.  This is important to many people for a variety of reasons.  For example, any online wallet or exchange company would typically need to run their own full nodes so that they don't have to rely on others for their core business.  There are many other reasons to run a full node as well, which will help to counteract centralization.


Why did Bitcoin first start to gain economic value?

Satoshi created a system that:

Allowed users to trust transactions without having to trust any single entity.
Opened it up so that anyone could participate and exchange computation power for Bitcoins.
Is designing with a fixed size (21 million Bitcoins), he created an incentive for users to get involved early while Bitcoins are relatively cheap to generate; there is less risk of future inflation reducing the value of early adopters.


How can I hold Bitcoins safely in the long term?

You can store the bitcoins in wallet on desktop or mobile. As it's software, you can create multiple copies of the keys and keep it in different devices, say USB, email, desktop, mobile, drop box etc

Yes you can also store it as paper, but it would be humongous to do on your own.


API to send bitcoins from paper/cold wallet?

You can just do it yourself instead of having to send a 3rd party your private keys. Here's one that I wrote using nodejs and bitcore-lib that takes a WIF and sends all funds to a different address.

https://github.com/coinables/sweepkey/blob/master/app.js


Why does some transactions have an excessive number of receiving addresses?

It is unlikely that someone would send money to that many business
  partners at once

Why? It's a mass payment for "shareholders". In this instance, the transaction you mentioned is a known payment from a pool to their miners.


Is periodically transferring Bitcoin from an exchange to a private wallet cost effective?

But I know that moving it from the exchange to the wallet will incur a blockchain fee

There is a fee involved in all bitcoin transactions which goes to miners. However, withdrawal fees of most of the exchanges are not same as the fee used in bitcoin transaction for withdrawal. Most of these exchanges have fixed withdrawal fee like 0.005 BTC on Binance. Some don't have withdrawal fees like FTX (Maybe promotion and won't be free forever). Some exchanges allow you to set your own fee like Bitmex (Minimum fee changes according to mempool)
Spot exchanges also have their own fee structure for withdrawals. Peer to Peer exchange like HodlHodl uses 2 of 3 multisig so fees work differently and you don't keep bitcoin on exchange ever: https://hodlhodl.com/pages/faq

What's the must cost effective way of moving it to my wallet?

There are different types of fees involved in exchanges. You will have to explore all options and see what works best for you. Also prefer using an exchange that supports withdrawal to segwit addresses, LN and Liquid. Layer 2 solutions have lower fees compared to on-chain transactions most of the times.
I am going to make a list of exchanges that support latest bitcoin technologies soon. Until then this link can be helpful for exchanges that support LN: https://ln.guide/docs/EXCHANGES.html


Bitcoin charts: Moving average or exponential moving average

At the end of the Day this is a very trader specific questions. Trading with a moving average system is dependent on the traders preference. If you do not understand the best way you personally should be trading, you are likely setting yourself up for failure from the beginning. I recommend you read "Trading for a Living" Dr. Van K Tharpe

There are hundreds of books written on trading with moving averages. There is no rule that works 100% of the time. 10 and 21 is traditionally used by institutions, but that does not mean you can't be successful with a 20 or 30.

You need to play with a moving average combination that works for you, and your personal trading style. I highly recommend paper trading you strategy before trading live with actual Bitcoin.

The biggest thing you need to figure out, is what type of trader you are, and the frequency of trades you want to be taking. If you are a day trader the 1 and 15 min may be what you need. If you are looking for a trade maybe once a week, the 5 and 10 might work. If you are looking to take trades over the course of weeks, 10 and 20 on daily chart. If you want a few trades a year 50 and 150 daily. Trading all of these time frames, could be over whelming, and just result in losses.

Any moving average combination can be used by any trader provided
1.) They are disciplined in the strategy
2.) Have back tested the strategy
3.) Have appropriate risk management

If you can not explain to someone exactly how your strategy approaches all three of the above points, you need to stop focusing on the moving average pair you are trading, and reevaluate what your trading strategy is.


Why did the price of bitcoin increase so dramatically?

some reasons for the price-increase:

-bitcoin becomes an official currency in japan

-Australia Will Recognize Bitcoin as Money and Protect Bitcoin Businesses, No Taxes

-many people know/buy bitcon now, who did not know bitcoin some months ago (in many countries) caused by increasing media coverage

-bitcoin becomes an alternative currency in venezuela, Nigeria and some other countries caused by internal political problems

-the scaling problem seems not to be finally solved but the segwit-activation could improve the scaling-situation

-Russia’s Parliament is Discussing the Legalization of Bitcoin

-meanwhile the blockchain-technology is more established: there are no known hacks of the blockchain self


Is the price of BTC transactions driven down by the influx of miners?

No, it is because those are unrelated values. The number of miners (more preciselly the cumulative hash power) influences the security of the network, but not the speed of mining the blocks (in long term). In short term (within the current window of 2016 blocks), it can influence the block generation speed, but after the window completes, difficulty retarget happens, so that the block generation speed goes back to designed avg. time of 10 minutes.

The transactions can not be confirmed faster than blocks are generated, thus block generating speed is very closely related with transaction [confirmation] speed.

Transaction speed is also influenced by number of transactions waiting to be confirmed, but that again is unrelated to number of miners.

Similarly the price is more or less unrelated (assuming enough miners to avoid monopoly). The price (per byte of serialized transaction) is mostly affected by the demand - i.e. the number of other transactions waiting for confirmation and their size and fee used and some other subtle properties.


Transferring Bitcoins from Wallet to Wallet

1) The exchange that has your bitcoin should have the option to withdraw bitcoins. It will then ask you to what bitcoin address you want to withdraw and how much.

2) The exchange you want to transfer the bitcoin to should have the option to deposit bitcoins, which will give you a bitcoin address to transfer to.

3) You can then directly withdraw your bitcoins to your deposit address.

4) Almost always these kinds of withdrawals and deposits are free except for the miner's fee, which will usually be BTC 0.0001.

5) No, exchange for cash is not always supported. I don't think a lot of exchanges would support this at all actually (unless by cash you also mean bank transfers?)


Connect C-lightning to a remote bitcoind through tor

Yes but not by default.
C-lightning uses a pluggable Bitcoin backend. The default one, bcli, will use the bitcoin-cli executable to make requests to a bitcoind.
It exposes bitcoin-cli's rpcconnect startup option to lightningd which does not not support onion hosts. And you probably don't want it to as it is not meant to be exposed.
If you want to run C-lightning without having the full block chain locally you'd probably opt for a light backend solution, such as:

A pruned bitcoind (beware of misconfiguration)
An explorer-backed backend.
For example, the Sauron plugin which you could connect to an external
Esplora instance you would run on a machine with more space. It supports onion services.

If you really want to remotely access bitcoind's RPC, you should probably opt for an SSH tunnel.


You will not be able to do that easily even if you have the private key Since bitcoin cash doesn't support Segwit, so you have to edit source code and mine that transaction by yourself.

Helpful links:

Bitcoin Cash SegWit hack

Recovering BCH sent to Segwit addresses


Is there any way to get the block number of generation from coinbase?

Blocks with a version of 2 or greater are required to put their block height in the coinbase. Your example doesn't. (At some point in the future, version 1 blocks will probably be discouraged and then banned.)

Here's an example of one that does:

038232030650b25c7d0f8bfabe6d6d0ebaccab777b7b5f4745bc81a22654d2fde018c3e8f06823670f5e790cbde3b6010000000000000000454d432055533300

The block height is the first thing in the coinbase. 03 is how many bytes the number has. So the number is 0x823203 in Bitcoin's little endian byte ordering, or 0x033282 in the big-endian byte ordering that humans usually use. Convert this into decimal and you can see that this is block #209538.


Accidentally sent Blockchain BCH to Coinbase BTC?

There is no way to directly retrieve your fund since they are the one now owning your coins, maybe try to contact their support directly on their social network like twitter to accelerate https://twitter.com/coinbase


Trade-offs in 2 of 3 multisig release transaction

To state the obvious in a 2-of-3 multisig escrow if two parties collude they can cheat the honest third party.

Buyer and seller signing the transaction. HodlHodl signs the transaction only in case of dispute.

In this scenario it is less work for HodlHodl and less trust/reliance on HodlHodl. You would choose this if you don't trust HodlHodl any more than the buyer and would rather only rely on HodlHodl in the case of the buyer becoming unresponsive.

Seller and HodlHodl signs the transaction. Buyer signs the transaction only when dispute.

In this scenario it is more work for HodlHodl and more trust/reliance on HodlHodl. You would choose this if you trust HodlHodl more than you do the buyer and HodlHodl are willing to get involved in a greater number of escrow releases. If they can avoid it HodlHodl would rather not get involved as when they do there is the possibility of mistakenly or maliciously releasing the money from the escrow when it shouldn't yet be released or releasing it to the wrong party.

Will the trade-offs remain same for any other similar bitcoin projects using 2 of 3 multisig?

Yes. As long as there are three keys being distributed to three parties there is this concern of two parties colluding to cheat the honest party. Note that some 2-of-3 multisig use cases distribute all three keys to the same individual so the individual can simultaneously protect their funds and offer redundancy in case the individual loses one of the keys. Other 2-of-3 multisig use cases (e.g. BitGo) give two keys to the same individual with BitGo keeping the third key. In this case BitGo can't steal the funds without obtaining an additional key from the individual.


What are the problems with normal currency that may be solved by using Bitcoins?

Paper fiat currencies issued by Governments could work perfectly well, provided they used the money for the benefit of society.
IE, if they  had the discipline of the Bitcoin code, we wouldn't need Bitcoin, the trouble is, Govts become corrupted, they are tempted to fund projects they can't afford or otherwise should not get involved in (wars) by printing money.
Printing money is a phrase we see bandied around a great deal, but if Govts only printed new money to pay for their pet projects, it wouldn't be so bad, what compounds the issue is that they BORROW this extra money from Private international Bankers who simply conjure the money out of thin air.
Taxes against the People are required to pay back this totally unnecessary Borrowing.
For more on this goto youtube and search 'Bill Still' 'the secrets of OZ' 'fiat money' 'fractional reserve lending'
More money in circulation means the money you have earned is devalued through inflation. Yes, you may still have $1000 in the Bank, but it's purchasing power is being devalued, it is becoming worth less because of all the extra money  being printed (borrowed) and put into circulation.
Another problem with central control is the issue of Liberty, currently, as in the case of Julian Assange, the state can freeze your assets, switch off your access to banking.
This is potentially very sinister, do some research and you will see that totalitarian Govts often shut off access to money, food and water as a means of controlling large numbers of people.
Bitcoin addresses several of these important issues, firstly, it's a limited supply, whereas there is virtually unrestrained money printing going on, and there might even be new Gold and Silver deposits found, there will NEVER be more than 21 Million BTCs. These are divisible up to 8 Billion times so BTC has the potential to serve as a Global currency. There's no central control, Your Bitcoins cannot be blocked as they are sent person to person.
As people buy in, driving the price higher, instead of buying a meal for 1 BTC we will be using fractions of a BTC, a whole BTC becoming worth a considerable amount of money, this is called deflation, this is the opposite of what we have now with inflation devaluing our currency.

Pensions too could be transformed by this, simply work 20 to thirty years, buying BTC allowing them to deflate (increase in value) to a sizeable Nest egg, then retire when YOU want to.,
Currently, there's money pouring into Bitcoin, people say it's a speculative bubble that may eventually crash.
I believe though that Bitcoin is a Global asset, it is a peer to peer, anonymous version of Western Union, so if Bitcoin has no value then Western Union has no use to society either.
I think the thing that will determine bitcoin's ultimate success is if underneath the speculation, real industry and businesses can spring up using BTC.
For those early adopters who've gained, probably the best way to preserve those BTC Gains is to take 1% of your gains and help young BTC industries to flourish.


When mining, you computer creates hashes. These hashes must satisfy a certain condition. All a miner does is trying many many times to find a valid hash for a block.

For this reason, mining hardware performance is measured in GH/s, giga-hash-per-second, which are one billion hash calculations per second and it is called the hashrate.

It is good to know that there is no fixed amount if hashes required to find a valid hash. The Bitcoin network has a dynamic difficulty for the mining problem. This difficulty is used to make sure new bitcoins are generated at a predictable rate. The difficulty is changed every 2016 blocks, and is adapted so that it will take as close as possible to 2 weeks for the next 2016 blocks. This means that, at average, every 10 minutes a new block is found.

The chance of finding a good hash within such 2 weeks is fixed. This means that you can find one after only a few tries or it can take you weeks or even months to find one. When the total hashrate of the network raises, 2016 blocks will be found in less than 2 weeks. In this case the difficulty will automatically be adapted so that the next 2016 blocks will take 2 weeks, considering the recent hashrate change.


NXT, Ignis, and Ardor Confusion. Purpose of NXT when there is Ignis / Ardor?

If NXT is switching to Ardor, what is the purpose of holding NXT?

Nxt isn't switching to Ardor. It will still exist after Ardor launches. The purpose of holding NXT with this in mind is if you need to use the Nxt blockchain, either for personal use or projects, since one will need NXT for the transaction fees, etc. Another reason could be the speculation of that use, since the amount of NXT in the network is fixed. (I'm not saying one should or shouldn't buy NXT for these reasons. Just pointing out some possible reasons of holding NXT)

  There is another snapshot that's happening with NXT for the coin Ignis, but how what's the purpose of Ardor then?

Ignis will be the first child chain on Ardor. Think of Ardor as this giant mechanical robot torso and head. It has everything needed for processing but doesn't really have a lot of features beyond processing, and maybe transferring some data around itself. (There will be almost no features on the Ardor main chain and just the ability to transfer ARDR and forge) Child chains are like the limbs that can be attached to this robot. They can do all the cool things while being powered by the robot torso and head.

With Ardor, there can be multiple child chains. So, if one wants their own blockchain without the problems of having enough nodes, etc., then creating a child chain would be an ideal option. Transaction fees will be paid in the child chain token and not in ARDR, though each child chain will need a bundler in order to collect these fees and pay the main chain in ARDR for processing the bundled transactions.

  So is Ignis the new NXT?

Ignis will have a lot of the features on Nxt but will not be the new Nxt. Probably the biggest difference is that all transaction records of Ignis will be pruned after 1440 blocks (~24 hours). Meanwhile, transaction records on Nxt will not be pruned. While there will likely be a archival nodes for Ignis, this might not be desired by some people for their projects, so running it on Nxt would be better. This would also be true if the project doesn't necessarily require all of the features a child chain would bring as creating a child chain won't be cheap. I'm not sure what the price will be yet, but testnet will probably give us a better idea.


Upgrade to 0.21.0 - No incomming connections via Tor after upgrading

I think everybody using Tor with the newest Core has the same problem, including myself. There’s a Good explanation here why this is happening:
https://www.reddit.com/r/Bitcoin/comments/kzhhgk/bitcoin_core_0210_tor_v3/
My solution was to roll back (for now) to the previous version. It now works fine.
I still do not understand why this appears not to be backwards compatible with Tor v2. As the official bulletin release clearly states:
“This release adds support for Tor version 3 hidden services, and rumoring them over the network to other peers using BIP155. Version 2 hidden services are still fully supported by Bitcoin Core, but the Tor network will start deprecating them in the coming months. “


Can I have a transaction where the source and destination are the same?

Yes, it is possible to send to the same address. However, to prove control of an address, you could instead sign a message.


Transfer to Bitcoin ABC wallet is waiting for full download

You could use wallet software that does not require downloading of the blockchain, in the same way electrum.org does for Bitcoin.


How to sign a raw multisig transaction from an external private key

The Bitcoin Wiki entry for OP_CHECKSIG answers your question. OP_CHECKMULTISIG works the same way, just applied to each signature in the sequence.

First of all, it depends on the SIGHASH type you, as the signer, choose. Most likely you will use the default SIGHASH_ALL for each of the required signatures, but you could actually use different SIGHASH methods for each individual signature.

Since you mentioned bcoin, you can review the signature hash methods in lib/primitives/tx.js here, and in the methods immediately following.

Very briefly:

The SIGHASH_ALL method will serialize all the inputs* and all the outputs of the transaction, including the nLocktime, and sign that blob.

*The input scripts are all replaced with a sinlge 0x00 byte. The script of the input being signed/checked is replaced by the corresponding output script from the funding transaction. So actually, the hex string you posted (the templated input script 000000004c695...) is the only part of the transaction that will NOT be signed by any of the multisig participants for this input!

bonus tidbit: The 2-of-3 signature template has FOUR OP_0's. Why? Well. the first one is popped off the stack by OP_CHECKMULTISIG, that's a bug Satoshi left us with. The other three are placeholders for the actual signatures. There are THREE instead of just TWO because the signatures need to be in the same order as the pubKeys in the redeem script. The extra placeholder is removed before broadcasting the transaction. In bcoin, this script template is assembled here.


Bitcoin core's estimatesmartfee gives same estimate on ECONOMICAL and CONSERVATIVE mode

The two modes don't just unconditionally return the same thing. They do different calculations and can return different results under certain conditions, particularly when fees are very variable for low confirmation targets. The current fee situation just makes it so that the estimator ends up using the same values for both modes.


What would happen if there are more blockchain imitators like Factom?

The way Factom works, they store the merkle root of the various hashes on the blockchain in an OP_RETURN output. This amounts to 80 bytes in the OP_RETURN and the actual transaction is going to be on the order of 500 bytes. The way they scale is that they store the actual merkle tree elsewhere and only put the root into the blockchain, about once per block.

Assuming that everyone uses Factom, this would mean that the blockchain would only get one Factom transaction per block, which is what it's already doing. If there were a million other services using OP_RETURN, then no, currently, the block size is limited to 1MB per block, which can only take about 2000 such transactions per block.


Is it possible to get ticker of bitcoin.de using an api?

You could just parse the website. For example to get the current euro and us dollar prices:

curl -s https://www.bitcoin.de/de | sed -n '/EUR/s%.*[^0-9]\([0-9]\+\)\(,\)\([0-9]\+\).*%\1.\3%p'

curl -s https://www.bitcoin.de/de | sed -n '/USD/s%.*[^0-9]\([0-9]\+\)\(,\)\([0-9]\+\).*%\1.\3%p'


Can I spend utxos from various bip32 subwallets in only one transaction?

a Bitcoin transaction can have between 1 and (realistically) several hundred inputs, each of which can redeem completely unrelated UTXOs. Whether or not the keys for those UTXOs are related through BIP32 or some other scheme is not relevant, and even not observable by the network (it is not possible to correlate different BIP32 keys unless you know their master key).


When and how does bitcoin node sync itself?

Always.

When starting up, Bitcoin Core sends out a request to its peers to inform it about the best chains they know about (using a getheaders message).

After that point, it is automatic: peers will immediately announce new blocks they knew about after they learn about them. This either happens using:

legacy inv mechanism, in which case just block hashes are announced
BIP130 (if negotiated), in which case announcements send full block headers
BIP152 high-bandwidth mode (if negotiated), in which case blocks are immediately transferred in full using compact blocks protocol


You need to supply an extra option to compile a QT binary.

./autogen.sh
./configure --with-qt
make -j8

Your binary will then be in /src/qt/ as expected. To turn it into an .app you'll need to read contrib/macdeploy/readme.md and then run make deploy to wrap it in an application bundle ready for release.


Miner username and password - does it need to be unique in the major pools?

Usually the worker's username is appended to your account username. So if my pool username is nmat, my workers will be named nmat_rig1, nmat_rig2, nmat_FPGA, etc.

Creating multiple worker accounts is useful to control the performance of your rigs, but is not mandatory to use a different identifier for each machine. You can have all your rigs mining with the same username/password and the money will still end up in your account.


Check this: https://en.bitcoin.it/wiki/Testnet

The testnet is an alternative Bitcoin block chain, to be used for testing. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.


real time number of transactions world wide

You would have to monitor the block chain yourself, like you say I think it would count as abuse if you poll blockchain.info every single second of every day. The block chain is just a database so if you have programming skills or are willing to pay someone with the skills it wouldn't be too difficult.

There are probably tools out there already that could do this such as libbitcoin, bitcoinj, etc. I'm not sure. You could even modify the official bitcoind client to log every transaction it receives to a database/textfile/whatever.

FYI the listtransactions RPC call will only list your own transactions, not everybodys.


what is 111...1114oLvT2?

See also here, it explains in detail on the logic behind „proof of burn“, including op_return.

  why 14,270 BTC?

We cannot know. Pure speculation would be, that people write scripts, to do a proof of burn. Or also, they could provide a P2SH tx, where the hash of a text is provided. Think of it as „I can proof, that I had a data, that I published as a ahah into the bitcoin blockchain“ (proof of existence). Also one could think of a recurring payout from a faucet or mining contract. We don‘t know.

  why unable to decode?

answered by Nate


Version prefix used for Bech32 addresses

Those bytes (x03x03x00x02x03 or better shown as 0x0303000203) are the expanded human readable part. You can find the code on BIP-173.
def bech32_hrp_expand(s):
  return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]

The problem however is that unlike Base58 encoding, those bytes are only used in calculation of checksum not as the starting bytes. Which makes the picture misleading in my opinion.
Bech32 encoding is very different from Base58 encoding as there is no "version prefix". There is an Hrp, a witness version, a data (hash) and a checksum. Witness version | hash are the data being encoded and expanded_hrp | data is used in checksum calculation (| is concatination).


Is this scheme for multisig audit of Trezor + Coldcard ok?

The wallets can have a malicious random number generator.

There are several ways to be malicious. Typically random number generators are considered malicious when they are
somehow predictable, so if you use them someone else can guess your "random number".
But that doesn't seem like what your plan protects you from.
What you verify with your procedure is that your hardware wallet do not give you a different seed (when you do the initial setup or ask to export it) from the one it used to generate the private keys and related addresses, that it uses when you receive or send funds with him.
In this meaning, the seed (from which private and public keys are derived in HD wallets) would not be yours but belong only to your hardware wallet: you can receive and send using the device, but if you import the seed elsewhere there are no associated funds, because it's different from the one used by Trezor.
However I have never heard of such a problem on any hardware wallet.

The wallets can generate address for keys that are not mine

This don't make sense to me, public addresses are derived from private keys, so the wallet need to have the private
keys to generate addresses  ... i'm not sure what you mean.
Furthermore, you can't verify that you are the sole owner of a seed or a private key, the most you can do is make
sure that this does not leak out, but if somehow someone manages to copy, predict or generate it randomly, you can't
notice until the money goes away.
So, all things considered, I think you can avoid having to verify the seeds that your wallets give you, because this
adds practically nothing to the security you already have using multisig addresses with 2 hardware wallets evaluated
as Trezor and Coldwallet, that are already heavily scrutinized, as you can see here for example.

PS: I know that if the trezor has a malicious random number generator and it creates a private key that not only myself own, this is a privacy leak, but not a problem. And it's a privacy leak only when I spend from this address, revealing the public key on the blockchain.

I'm not aware of troubles with Trezor rng (have you any reference for this?), but if your private keys are leaked you will lose your funds almost istantly, there is no need to wait you spend, as said before, public key and addresses derive from private key, so if you have this you don't need anything else


How do I create release build of my new bitcoin wallet?

Bitcoin statically links in all of its dependencies by default, because many of them are consensus-critical and cannot accept a different version. Therefore, you can distribute the binaries that make creates.

However, I would recommend setting up gitian deterministic builds.


Found a helpful post at litecointalk:

  It won't work because the aux work must be explicitly provided by the merge coin.  All of these coins cloned from Litecoin lack that code as Litecoin doesn't have it.  As a result you cannot merge mine these coins.

  It is the same reason you can't merge mine Terracoin or Freicoin with Bitcoin.  Freicoin considered it in the past as means to stabilize their network, but I'm guessing they decided against it because they are afraid of their value collapsing even more.  Trouble is none of the small PoW coins are able to maintain a stable network if they are subject to sudden reorg attacks at any moment as many of the scrypt clone networks often experience.  Thus avoiding merge coins to preserve "value" is illusory and self-defeating.

Also, apparently there is a scrypt coin designed for merged mining with Litecoin called UnitedScryptCoin, though I didn't have a chance to try it yet. Link to UnitedScryptCoin thread in bitcointalk.


Currency exchanges are implemented through programs called order-matching engines. When a new order is entered, a buy order for example, the matching engine checks to see if there is a match on the other side, a sell order at the right price.

Bid is the price a user is willing to pay and Ask is the price at which a seller is willing to sell. The difference between the two is called the spread. Most exchanges try to minimize the spread. The price often quoted is midway between the highest bid and the lowest ask.

Here are some examples of matching engines: https://github.com/jordanbaucke/Limit-Order-Book


For lightning network, can I surround myself with a bunch of nodes to increase anonymity?

Every node you spin up will have to have Bitcoins that you can lock up to put into the payment channels it creates. Nothing is stopping you from starting a new node (and payment channel) for every node you transact with. And as long as none of the Bitcoins you used were connected to each other it wouldn't be very easy to prove those nodes were controlled by the same entity.


Search and delete bitcoin core and other related files to reduce attack surface

No

No. What happens to wallet.dat if I uninstall and re-install on Windows Bitcoin desktop client?

Depends on the user and it's good to delete such files from system that will not be used anymore if you have backup.

Scanning bitcoin core related important files with an open source tool: https://github.com/deepfence/SecretScanner
It will search for lot of files including 3 related to Bitcoin Core:
  - part:  'filename'
    match: 'wallet.dat'
    name: 'Bitcoin Core wallet'
  - part:  'filename'
    match: 'onion_v3_private_key'
    name: 'Private key for Bitcoin Core onion service'
  - part:  'filename'
    match: 'bitcoin.conf'
    name: 'Bitcoin Core config'

https://github.com/deepfence/SecretScanner/blob/779b22df6d536b54bc4fb74fdf56d582f008f4a0/config.yaml#L477
Maybe we can even add debug.log in this.
A blog post about "Detecting secrets to reduce attack surface": https://medium.com/deepfence-cloud-native-security/detecting-secrets-to-reduce-attack-surface-3405ee6329b5
TLDR:

Secrets are as important as vulnerabilities from cybersecurity point of view, as attackers can very easily get backdoor access into customer infrastructure and spread laterally to launch multi-stage attacks due to leakage of secrets.


Your description works well enough until you start talking about encryption. The way you've described implementing public-key cryptography isn't quite right, if you're interested, I would suggest taking a looking at at the public-key cryptography wiki page.

I think more useful than explaining how your description is wrong, I'll just give an example of how I would re-write it to be more accurate (at least insofar as it is implemented in bitcoin). My addition in bold:

  How would the databases verify that you are in fact doing the transaction and not someone saying that they are doing it? Through public and private keys, right. Coins can be sent to public keys, and then spent using the corresponding private key. So you can share your 'pubkeyA' with someone, and then they can send bitcoins to that key (and thus to you). They do this by using their 'privkeyX' to sign a transaction that says "send the coins held at 'pubkeyX' to pubkeyA", and everyone else can use the pubkeyX to verify that the signature came from privkeyX, without ever knowing what privkeyX is!

Perhaps also worth mentioning, saying 'databases that everyone has access to and can write to' is sorta misleading, it makes me think of a database instance that many different people write to. In reality it is 'many instances of a database that are constantly updating according to the network's rules'.

  A lot of people's computers verify the transaction so it's safe. Why is mining even necessary?

Proof-of-work mining solves the problem of needing a large network of untrusted computers to all agree upon the ordering of transactions, in order to solve the doublespend problem. Otherwise, how will the computers agree on which transactions to include, and in what order? What would make any one copy of the database more trustworthy and accurate than any other?


Install bitcoin core on debian jessie error

The repository is for ubuntu and you're on debian.
So it doesn't have packages for jessie.
Use this instead: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
Hope this helps! :)


Am I legally allowed to accept fiat currency online and return a counterparty asset/token?

It depends on where you live, where you sell and who the buyer is.

If your jurisdiction regulates this stuff or your buyer is say, a US citizen, regulations may apply. You may be able to work around that by implementing certain basic rules such KYC/AML, either full blown, or basic (such as the user confirming they're not a US resident or citizen, etc.)

There are several games that do exactly that on the Counterparty platform without issues, but that doesn't mean anyone can do it.

Recently there's been a growing number of regulations about ICOs and "tokens", so best check with someone who understands laws and regulations that apply to your territory and is qualified to give legal advice.


Try opening your data directory and deleting the file .lock

Make sure Bitcoin is closed while you're doing this.


The term for such a site is block explorer and there are many of them.  Among the top Google hits for "block explorer" are:

http://blockexplorer.com
http://blockchain.info
http://biteasy.com
http://blocktrail.com
http://btc.blockr.io
http://bkchain.org


Bitcoin Cash is technically just Bitcoin before the fork, it doesn't really exist as such, and any Bitcoin you own will become Bitcoin Cash as well after the fork (because your UTXOs will be valid in the shared chain before the fork and thus valid in both branches). Until the fork happens, there is only one blockchain, hence the term fork.


How can a X-coin market cap go down while its value goes up?

As Nate Eldredge pointed out, the chart you're looking at is denominated in BTC, while the market cap is denominated in USD.

If you look at the chart below, you'll see that the price in USD (green) behaves exactly as you describe in your question.

On the other hand, the price in BTC (orange) does not behave like you expected, because it combines the price movement of Bitcoin with the price movement Zcash respective to the Market Cap denominated in USD (blue).


How to interact with bitcoind using C++?


What are cash outlays & expected inflows for an individual miner?

There are a bunch of mining profitability calculators here. You just need to fill in how much you're going to spend on the equipment, what sort of hash rate you get from the equipment, how much you pay for electricity and what you think bitcoin will be worth and it'll tell you. These are all highly dependent on what you buy, how much of it you buy, where in the world you are and what bitcoin price will be. Investment yields will differ based on those factors.

An ASIC machine manufactured 2 years ago in Paris is going to be much less profitable (or basically lose lots of money) vs. getting a bulk discount on the latest ASICs in Iceland.

Also, this is a question that gets asked quite often.


Is Bitcoin mining pools safe to invest with?

In general, get rich quick schemes are a scam.

Mining pools themselves are safe to mine with, but I do not know of any official investment schemes. Do not send your money.


What are the 3 arguments called in function SHA256?

Let's disect this function call:

void sha256(struct sha256 *sha, const void *p, size_t size)

First we realize that the return value is void which means the function does not return the sha256 of the data. However we see that the first argument struct sha256 *sha is a pointer to a sha256 struct with the name sha. This suggests that the pointer that we pass to the function will afterwards contain the computed hash.

The second argument const void *p is a constant void pointer. This means that the function does not care about the data type of the data for which it computes the hash and it will not be able to modify the memory to which the pointer points to. This makes sense when we want to compute the hash of some data we don't want this data to be changed. Also computing the hash is a binary operation which is possible on the binary representation of any datatype.

This brings us to the third argument size_t size which is supposed to be the size of the data the second argument points to. I assume there is somewhere a typedef statement defining size_t as an integer. As the second argument is just a pointer to the data struct for which to compute the hash the function needs to know how much memory to process.


Receiving dollars directly into bitcoin wallet?

BitPay appears to have an all-in-one solution that allows you to set up a store checkout in a lot of different currencies that will be handled through the use of Bitcoins. As I don't have a hands-on experience with that, I can't vouch for how the system works.

Another convenient way of setting up a payment system would be to use BitInstant which allows a user to quickly convert cash into Bitcoins through a variety of ways. It does not appear to be as automated as BitPay though, and you would have to handle your own payments.

Lastly, you can encourage your users to get their Bitcoins through more traditional means, such as the use of Bitcoin Exchanges. This option also requires you to handle the payments by yourself.


How can you tell a block is Classic vs Core?

Ah, not surprisingly, it's in the block's "version" field. It looks like core blocks are versioned as "v4", while "classic" blocks are versioned as "v805306368" and "BIP109".


Best way to mix bitcoins? mixer, coin join (shared send), dark wallet, stealth addresses?

I would say connect to tor, create a blockchain.info account, send you bitcoin there, then send the bitcoin to https://shapeshift.io to another currency which you have a wallet setup, then back to a second blockchain account, then to wherever you want.

This is pretty much 100% untraceable, as it goes via anonymous wallet - anonymouswallet - converted to another blockchain, sent to anonymous wallet, then converted back to bitcoin through another anonymous wallet! You can't track that transaction on the blockchain.

Enjoy :)