Clone bitcoin core repo, build and test it yourself: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests

Be active on https://bitcoin.stackexchange.com to learn and contribute

Experiment with bitcoin core GUI (qt) and CLI with different RPC commands mentioned here: https://bitcoincore.org/en/doc/0.21.0/ on testnet and regtest

Once you understand how things work, start looking for issues in https://github.com/bitcoin/bitcoin/issues that you can resolve or start with "Good first issues" with pull requests or create issues if you find something wrong while testing.

Participate in Bitcoin Core PR Review Club meetings: https://bitcoincore.reviews/

You can also start reviewing other PRs because bitcoin core has fewer devs to review a lot of code which delays things.

IRC channels that can be helpful apart from few technical posts on r/bitcoin, blogs of bitcoin devs etc.: #bitcoin-core-dev #bitcoin-core-pr-reviews ##bitcoin-core-gui


Why bitcoind will shutdown after encryptwallet?

This behaviour has been resolved by 12493. As stated by Andrew Chow in the pull request, this was previously done to:

  ...prevent the BDB environment from
  writing unencrypted private keys to disk in the database log files, as
  was noted here. This PR replaces the shutdown behavior with a CDBEnv
  flush, close, and reopen which achieves the same effect: everything is
  cleanly flushed and closed, the log files are removed, and then the
  environment reopened to continue normal operation.

  To ensure that no unencrypted private keys are in the log files after
  encrypting the wallet, I wrote this script to pull private keys from
  the original wallet file and searches for these keys in the log files
  (note that you will have to change your file paths to make it work on
  your own machine).

  As for concerns about private keys being written to slack space or
  being kept in memory, these behaviors no longer exist after the
  original wallet encryption PR and the shutting down solution from
  2011.


Salvaged possible wallet from corrupt HDD ... now what?

Install Python 2.7 and download pywallet to your c:\ drive.
Copy your corrupt wallet.dat file to c:\
Open a Command Prompt and type:

C:\>pywallet.py --dumpwallet --datadir c:\  --wallet=wallet.dat --recover --recov_device=c:\wallet.dat --recov_size=416Gio --recov_outputdir=c:\

It should extract all the keys to a new wallet on c:\
Copy the new wallet.dat to the c:\users\USERNAME\Appdata\Roaming\Bitcoin folder
rename it wallet.dat.
Start up Bitcoin-QT with the --rescan switch.
It should take a while, but eventually it will start up and your coins are back.


What hashing speed does my hardware have?

From Wiki:Mining hardware comparison: Core 2 Quad Q9650 - 18.67 Mhash/s . With current price and difficulty factor there is no point in using CPU for mining because the profit won't cover the cost of hardware or electricity. For example with current difficulty it will take you 8 years on average to uncover block and earn 50 BTC or 1/2 BTC a month if mining from a pool.

Today everyone uses video cards to mine e.g. ATI 5970 has about 800 Mhash/s, which is about 43 times faster then your CPU. Bitcoin network adjusts difficulty factor so bitcoin production rate would stay roughly the same, about 50 bitcoins per 10 minutes. CPU mining can do only a small part of total workload therefore you would receive on average a very small part of the reward.


What counts as verification or validation of a transaction?

A transaction is a output generated from a end-user's wallet software. It contains their address, the recipients address, and the amount to be transferred (among other things). After the wallet creates the transaction it then broadcasts it to the peers you are connected to and is added to a queue to be confirmed. The world will know, semi-immediately, that you have broadcasted this transaction, with a current status of unconfirmed. The transaction can now be viewed on a blockchain explorer with the txhash that was generated (a unique identifier of that transaction).

Miners confirm transactions in the queue by expending electrical power and processing power. After a transaction has been confirmed it is then added to a block. Once the entire block has been generated and confirmed, the transaction then stands at one confirmation.

Different sites and services require a varying amount of confirmations before doing certain actions.


How does one generate a paper wallet for a Lightning Bitcoin address?

A paper wallet is not the correct backup method for a lightning network Bitcoin address/channel.

To use a lightning network channel, you will need to have the private keys accessible to your lightning network software, so that the software can sign transactions to update the channel state. So the advantage of 'keeping your keys offline using a paper wallet' is not applicable: if your keys are offline, you cannot engage with the lightning network.

Further, to backup a lightning channel, you need more information than just the keypairs associated with the address, you also need information about the current state of the channel. A paper wallet generally refers to a physical record of a single keypair, so it is not designed to store this sort of channel-state information.

Further still, a lightning channel is represented by a multi-sig address, of which you will likely know only one of two (or more) keys. So printing out your key onto paper will be of very little use in being able to recover your funds later, since you will need the signatures of your counterparty's keys as well, in order to spend the multisig output.

I suppose if you really wanted to, you could print out the static channel backup file onto paper, but without a good way to later transcribe this information back to your computer, it seems like an unwise choice that will be prone to error.

It is advisable to follow the backup methods implemented in the popular lightning network clients, such as lnd's static channel backups. Here are the relevant commands, from lnd v0.6.0

exportchanbackup   Obtain a static channel back up for a selected channels, or all known channels
verifychanbackup   Verify an existing channel backup
restorechanbackup  Restore an existing single or multi-channel static channel backup


How do I get my public address in Bitcoin Core?

Edit: Answer to the question: How to get private keys out of Bitcoin Core

After you found your addresses (by using the commands I listed below, for example) you can execute the folllowing command:

dumpprivatekey 1ofYourAddresses

If your wallet is password protected and locked run:

walletpassphrase "your password or passphrase" 600

And 'walletlock' when you're done to re-lock it.

You can easily recognize addresses from Private Keys because addresses start always with one (1), Private Keys instead start with 5, K or L. You don't need to manage public keys at all. Also you just need the Private key to export/import a "wallet", in fact a private key is a wallet, and from that ypthe software can find out the address(es) that correspond to it, so you need just to export that.

Answer to the original question: How to get public address in Bitcoin Core
Note the account API is currently deprecated (being removed in new versions)

Your main (first) bitcoin account in Bitcoin Core and bitcoin-qt is the empty-string account, '""'.

To get your bitcoin addresses via bitcoin-cli or via the bitcoin-qt console, for your main account, use:

getaccountaddress ""

That will return your first address of the main account, and:

getaddressesbyaccount ""

Will return (at first launch two addresses and in general) the list of all your addresses associated with your main account.

This is an example output of the getaddressesbyaccount call on a newly installed bitcoin-qt:

> bitcoin-cli getaddressesbyaccount ""

[
    "1AA37Akj16aj9nU4NYgx2cRwjgmuwpxR6Z",
    "1CbkkAbB7ootHHu9Fhbh8TtRR2iiCoNCZD"
]

This is the minimal ~/.bitcoin/bitcoin.conf you want to have to be able to run bitcoin-qt with the CLI enabled, this way you can understand which accounts and addresses you own and their balances etc. from the UI.

rpcuser=bitcoin
rpcpassword=TYPE_A_STRONG_PASS_HERE

# enables deamon in bitcoin-qt
server=1


Lightning Network: hashlocks vs private keys exchange

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange?

Either way will work, but hashlocks are simpler. They're described in section 4 of the paper you linked. In a private key exchange-based system, you need to store every breach remedy transaction, (about 250 bytes) but in a hashlock system, you only need 20 bytes for each preimage.

You don't need to store every preimage, either. Murch explains and links a system to store every hash in a channel with 64*20 bytes of memory at most here: What is a hash pre-image as it is used for the breach remedy?


Processed withdrawal not reflecting in my blockchain wallet

The transaction shows for me. If it doesn't show for you, perhaps your wallet is out of sync or on the wrong chain. Easy thing to try is to restart the wallet.


The other two answers explain what has to be done to discover doublespends. I'll try to explain how it works.

There are no "balances", there are "coins"
A common misunderstanding is that there is a register of balances for addresses, and when you spend bitcoins, some of your balance gets deducted from your address. Actually, that's not a good description of what's happening. Under the hood, it's more akin to receiving a "coin" whenever you get paid, and drawing upon your available "coins" when spending.

Spending "coins"
When someone sends you a transaction, they create an "unspent transaction output (UTXO)". This UTXO is uniquely identifiable e.g. the first output of the transaction with the id X. UTXOs are like coins: They have a specific value and can only be spent completely. To spend part of one, you have to give up the complete coin, get back change.

Example:
You have two Unspent Transaction Outputs ("coins") worth 0.03 BTC and 0.09 BTC. They were created as "first output of transaction X" and "third output of transaction Y" respectively. You want to send 0.10 BTC to Bob.

You cite these specific two UTXOs as inputs to your transaction Z. I.e. you order "I want to spend the first output of transaction X, and the third output of transaction Y. I'm converting them to first and second output of transaction Z. – Here are the signatures for X.first and Y.third.".

X.first   0.03 BTC                       Z.first    0.10 BTC (spendable with Bob's signature)
                       ---- tx Z  --->
Y.third   0.09 BTC                       Z.second   0.02 BTC (spendable with your own signature)

In this example, you use up your two "coins", to give one "coin" to Bob to pay 0.10 BTC, and get back the change as another new "coin" which goes to yourself. Your transaction Z spent X.first and Y.third, and converted them to two new "coins" Z.first and Z.second.

Now, as described by Greg and Jestin, every full node has worked through the whole blockchain. Every single transaction references one or more "coins" that get spent, and creates new "coins" as in the example.

While a node works through the blockchain, it keeps track of the "coins" that exist, and updates this database with every transaction that happens. The database is referred to as the Bitcoin network's "Unspent Transaction Output Set". So, when you're up to date, the node has a list of every "coin" that is available for spending.

Back to the question
So, you sent 1 BTC to Bob one month ago. Now, you're trying to use the same "coins", X.first and Y.third a month later to send money to Carol. The nodes look at their "coin" database, and see that they are not in it. They can immediately say "Those coins have already been spent.".


Alternative: Mining scheme driven by logistic function

I think this is a viable idea and is worth exploring further, Are there any alt coins employing this function yet?

I have been thinking about it for over a year now and see that with Bitcoin by having the early adopters hold a majority of coins helps to preserve the original protocol, as those invested in the system stand to lose the most if it is changed.    The result is as the Bitcoin network grows the protocol and clients side use of the network is strengthened by the coins that will remain with the preferred fork.

With the normal distribution model facilitated by a logistic function, early adopters will not hold as much influence in keeping the original intent of the protocol intact, as early majority adopters will hold the most influence.

There are possible alternates like a proof of stake, mining option that could be reworded for maintaining the original blockchain, and can be redeemed/ utilised as a stake to mine, thus regulating mining growth with that of maintaining the growth in bandwidth and storage. (allowing for 2 specialisations: 1) mining coins - 2) maintaining the block chain.

The result is when mining jumps significantly: 1) early adopters can sell their mining options (maintaining the original protocall) 2) the market demand to mine more is held in balance with bandwidth and storage growth. (making it more environmentally viable and allowing for greater decentralised block chain storage.)

Ie. the protocol stake holders are the ones who maintain the block chain. And to do a 51% attack you would have to strengthen the base network, I can imagine preventing modification of the block chain.


Great IOTA tutorial playlist
https://www.youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza

IOTA tools from the playlist
https://www.mobilefish.com/services/cryptocurrency/cryptocurrency.php

IOTA and NodeJS tutorial
https://youtu.be/Z-NN0rRcwY0

Repository for above tutorial
https://github.com/iota-community/iota-workshop


Why is only the block header SHA256-hashed and not the whole block?

In fact, it is done over the whole block, but indirectly.

One of the members in the block header is the Merkle root hash of the transaction hashes. Effectively, that is a hash of all the transactions.

Because that field is included in the block header, the hash of the block header is effectively a hash of all transactions as well. If a transaction would change, its hash would change, the Merkle root would change, the block header would change, and finally the block hash would change as well.

Then why is this done? There are several reasons for the exact construction, but the most important one is probably the fact that it makes the speed of mining independent from the number of transactions.


Who provides a Bitcoin recurring payments API?

There is no ready-made recurring payment solution at the moment, however this can be achieved at application level by constructing pre-signed transactions or using CLTV's as @Wapac suggested. CLTV approach may have a downside though, you will be paying transaction fees twice in case you decide to cancel.

A more sophisticated mechanism may be creating a non-custodial, multi-sig wallet service that keeps track of your recurring payments and notify you if any action is needed. Disclosure, I am involved in such a solution called: https://www.arf.one


Would it be possible to send money through the Lightning Network to an offline address?

This sounds like a web wallet, where the keys were managed for you and you simply interact through a website.  You'd have to trust the third party, but as we've seen on the main network, this is acceptable to a great number of people.

Just like with the existing Bitcoin network, you have to run things yourself to be trustless, but there are more convenient options if you are willing to trust (and pay fees to) other parties.


Did Blockchain just ripped me of my bitcoin?

I would expect that Blockchain sets up your backup and security when you create an account. If you got prompted to put in your wallet information at a later time, that would have almost certainly been a phishing attack. I suspect that you were on a website that was not blockchain.info and the mock security setup provided the information to empty your account to your attacker.


How should a node deal with a block that is not connected to the chain?

The Bitcoin client used to download blocks without necessarily knowing if they could connect it to their current chain. If it couldn't connect a block to the genesis block, it would just keep it in memory. This was a waste of memory (up to 750 MB could be used up before it started dropping blocks) and bandwidth (if you drop a block that you need, that wastes bandwidth)

It does something smarter now, though. It builds a chain of block headers to the current tip of the chain, then downloads the block contents. Not only is this simpler, and more resource efficient, it also allows you to download multiple blocks in parallel. Blocks are written to disk as soon as they're downloaded.

Since there's no way that you will receive a block that you didn't ask for, the current Bitcoin client will drop the block and permanently disconnect from the peer that sent it.


What is a likely solution to Bitcoin's energy consumption problem?

I feel that a solution will have to be found

I'm not sure I agree there is a 'problem' that needs to be explicitly fixed. The article you linked explains the relationship between price and electricity usage, now remember that price is a measure of the demand (since the supply is fixed and known).

So the market acts as a naturally regulating force: as people pay more and more to buy and use bitcoin, the network's power consumption will increase (and vice versa). So to say "bitcoin uses too much energy!" is to say "bitcoin is worth less than the current market value!". The article linked supports this point, but you kind of have to 'read between the lines' to realize it is true.

Consider gold mining: if the price of gold were to rise, then it would become profitable to start mining gold in places where a more expensive  processes will be needed to extract the gold from the earth. Is it a problem that companies will spend a lot of energy to get this extra supply that is now worth while?

Interestingly, consider what happens if the demand for bitcoin continues to increase, to the point that the network is in direct competition with all other use cases for power. In that case, for the btc price to increase, electricity prices would have to be increased, effectively spreading the cost of mining across all of the world's energy usage (because if the demand for bitcoin did not exist, everyone would be paying less to power their home appliances, etc).

I think it is easy to say "this is a problem!!", but the less obvious realization is "bitcoin is using this much energy because the market considers it useful enough to be worth the cost"

  I'm just wondering if I missed another option and which of the options is most likely.

I don't think any of the three options you listed are likely to happen.

Another 'option' to consider is this: once mining chips become commodity (more easily and readily available from multiple suppliers), I think the nature of the mining competition will change. If everyone has access to good ASIC chips, then there will be immense competition to develop and utilize the cheapest sources of power available. What if bitcoin miners must help fund the development of ultra-efficient solar panels in order to maintain a competitive advantage? This is how ASIC miners were developed, why can't the same happen for another variable in the mining industry?

If this occurs, rather than the energy consumption of the network being a problem, it becomes an incentive for finding a solution to the larger issue of 'needing to develop green sources of power'.


how do you sign and verify a message that you own a bitcoin address using javascript?

bitcoinjs-lib and bitcore-lib are both javascript libraries that allow for key signing.

For example with bitcore-lib:

var Message = require('bitcore-message');

var privateKey = new bitcore.PrivateKey('L23PpjkBQqpAF4vbMHNfTZAb3KFPBSawQ7KinFTzz7dxq6TZX8UA');
var message = new Message('This is an example of a signed message.');

var signature = message.sign(privateKey);

EDIT: To also include the verification example from bitcore's github.

var Message = require('bitcore-message');

var address = '13Js7D3q4KvfSqgKN8LpNq57gcahrVc5JZ';
var signature = 'IBOvIfsAs/da1e36W8kw1cQOPqPVXCW5zJgNQ5kI8m57FycZXdeFmeyoIqJSREzE4W7vfDmdmPk0HokuJPvgPPE=';

var verified = new Message('This is an example of a signed message.').verify(address, signature);


Transaction order in the block

Currently, there are only two requirements for the order of transactions:

The coinbase transaction is always first.
Intra block dependencies must preceed, i.e. if Transaction A and Transaction B are both in the same block, and Transaction B spends outputs of Transaction A, A must be listed before B.

It is likely that in the future a correct order for transaction will be introduced, as this will allow proving the absence of a transaction in a block with logarithmic effort, and will allow more efficient block data propagation through IBLT. Right now, transactions are propagated in the network before confirmation, and then again as the content of a block. With a deterministic transaction order and IBLT set reconciliation, each transaction would only have to be received once instead of twice.

Building the Merkle Tree

The transactions are inserted into the Merkle Tree in the same order they are listed in the block. If a block only contains the Coinbase Transaction, the Coinbase's transaction ID is used as the Merkle Root.
Otherwise, a binary tree is created from the transactions by pairing transaction hashes on the first level, then pairing resulting hashes on each next level until only one hash results, which is then used as the Merkle Root. If there is an odd number of hashes to be paired, the last hash is paired with itself.

Further Reading

The Developer Reference has additional details. The image is from the Developer Reference as well, and hence licensed MIT.
Antonopoulos covers Merkle trees in detail in his book, also providing examples of how it is used to prove transaction presence in blocks.


What versioning scheme does Bitcoin Core follow?

Bitcoin Core does not follow semver. BitcoinCore.org explains its Software Life Cycle as follows:

Bitcoin Core aims to make a major release every 6-7 months.

Minor releases provide maintenance, fix bugs, and might introduce minor features. Proposed changes to consensus rules are always first shipped in minor releases, so that consensus rule changes can be adopted independently from the release of new major features.

Bitcoin Core releases are versioned as 0.MAJOR.MINOR, and release candidates are suffixed with rc#. Examples of each version type are:

release candidate: 0.12.0rc1
major version: 0.12.0
minor version: 0.12.1

Note that Bitcoin Core versions built directly from the master branch instead of a tagged release show up as 0.MAJOR.99.
Update in Dec 2020: The next "major" release after 0.21.0 will drop the leading zero and therefore be called 22.0.


What would be the second greatest bottleneck in the mining process? after the hash generation of course.

You make one call to bitcoind using getblocktemplate to get a template for a block. Then you can generate all the work you need.

In the fantasy world you would find a block instantly. You submit this block and get another template to create the next block.

You would be generating hundreds or thousands of blocks per second. The only thing to slow you down is bitcoind validating blocks and pushing them out on the network.

We will find out what the limit is as new alt coins are created daily, usually with the only "feature" being faster and faster block generation. Once we have an alt coin producing 1000 blocks per second, perhaps we will see some issues (other than disk space).


Create Sign and send bitcoin transaction using HD wallet

To spend any coins, you’ll need the private key corresponding to that bitcoin address.

In the case of an address derived from an xpub, you’ll need to use the xpriv that created the xpub to derive the child privkeys (they’ll be the same child pubkeys that the xpub derived, but this time you’ll have access to both child privkeys and pubkeys). As you know, it is not possible to derive the child privkeys from an xpub itself.


How is mining difficulty defined (formula)?

The nBits field is basically scientific notation in base-256 (256 is 2^8). As an example, we take the one found on the Bitcoin.org Developer Reference: 0x181bc330 (Big-Endian order). This is split into two parts, the 0x18 exponent (24 in decimal), and the 0x1bc330 mantissa. The mantissa is 3 bytes long, so subtract 3 from the exponent and then raise 256 to that power, and multiply by the mantissa just as in scientific notation:

  0x1bc330 × 256 ^ (0x18 - 3)

Giving the target, the mantissa followed by 21 0x00 bytes, or 42 zeroes in hexadecimal.

See this answer for another example: https://bitcoin.stackexchange.com/a/61967/51948

EDIT: You can also think of it as allocating the number of bytes given in the exponent, in this case 0x18=24 bytes, and than filling the first 3 bytes with the mantissa.


Who to rent virtual private server from accepts bitcoin?

You can find a list of VPS hosts on the Bitcoin Wiki page for Trade. Some of them list what countries they come from. There is also a neat list of all the VPS servers. At the time of writing, only CINIPAC appears to be anywhere close to your desired locations, being from Romania.


In Ripple, what is "Total XRP" in the ledger header?

This is the total amount of XRP in the ledger. It is decremented with each transaction that pays a fee (which is all of them except for a few special transactions). There is no way it can be incremented.


running bitcoin-cli -testnet getblockchaininfo

You can get information about each value on the RPC documentation on bitcoincore.org or by running bitcoin-cli help getblockchaininfo. I paste it below:

{
  "chain": "xxxx",              (string) current network name as defined in BIP70 (main, test, regtest)
  "blocks": xxxxxx,             (numeric) the current number of blocks processed in the server
  "headers": xxxxxx,            (numeric) the current number of headers we have validated
  "bestblockhash": "...",       (string) the hash of the currently best block
  "difficulty": xxxxxx,         (numeric) the current difficulty
  "mediantime": xxxxxx,         (numeric) median time for the current best block
  "verificationprogress": xxxx, (numeric) estimate of verification progress [0..1]
  "initialblockdownload": xxxx, (bool) (debug information) estimate of whether this node is in Initial Block Download mode.
  "chainwork": "xxxx"           (string) total amount of work in active chain, in hexadecimal
  "size_on_disk": xxxxxx,       (numeric) the estimated size of the block and undo files on disk
  "pruned": xx,                 (boolean) if the blocks are subject to pruning
  "pruneheight": xxxxxx,        (numeric) lowest-height complete block stored (only present if pruning is enabled)
  "automatic_pruning": xx,      (boolean) whether automatic pruning is enabled (only present if pruning is enabled)
  "prune_target_size": xxxxxx,  (numeric) the target size used by pruning (only present if automatic pruning is enabled)
  "softforks": [                (array) status of softforks in progress
     {
        "id": "xxxx",           (string) name of softfork
        "version": xx,          (numeric) block version
        "reject": {             (object) progress toward rejecting pre-softfork blocks
           "status": xx,        (boolean) true if threshold reached
        },
     }, ...
  ],
  "bip9_softforks": {           (object) status of BIP9 softforks in progress
     "xxxx" : {                 (string) name of the softfork
        "status": "xxxx",       (string) one of "defined", "started", "locked_in", "active", "failed"
        "bit": xx,              (numeric) the bit (0-28) in the block version field used to signal this softfork (only for "started" status)
        "startTime": xx,        (numeric) the minimum median time past of a block at which the bit gains its meaning
        "timeout": xx,          (numeric) the median time past of a block at which the deployment is considered failed if not yet locked in
        "since": xx,            (numeric) height of the first block to which the status applies
        "statistics": {         (object) numeric statistics about BIP9 signalling for a softfork (only for "started" status)
           "period": xx,        (numeric) the length in blocks of the BIP9 signalling period
           "threshold": xx,     (numeric) the number of blocks with the version bit set required to activate the feature
           "elapsed": xx,       (numeric) the number of blocks elapsed since the beginning of the current period
           "count": xx,         (numeric) the number of blocks with the version bit set in the current period
           "possible": xx       (boolean) returns false if there are not enough blocks left in this period to pass activation threshold
        }
     }
  }
  "warnings" : "...",           (string) any network and blockchain warnings.
}

The headers field means the number of block headers your node has validated, without validating whether the transactions inside that block are valid. Validating the header includes validating the difficulty, timestamp and blockhash fields and can be done without downloading the whole block. The headers must be equal or higher than the blocks field which indicates how many blocks have been fully validated.


Not yet.

We've just revamped the server side RPC internals in develop and are still ironing out some quirks. I can imagine we would soon-ish start working towards the directions of providing some Go client APIs, but we're not there yet. If you just need a few specific ones, they are relatively easy to implement (here's a few we needed for a hackathon last week https://github.com/gophergala2016/etherapis/blob/master/etherapis/geth/api.go).


I'm not exactly sure if this is what you're asking; nevertheless the wiki says:

  Transactions are signed locally: Your private keys are not shared with the server. You do not have to trust the server with your money.

  Freedom and Privacy: The server does not store user accounts. You are not tied to a particular server, and the server does not need to know you.

It seems the storage of your keys is client-side, so if they were to get (D)DoS'd you could easily move you keys to another wallet.


SegWit, Bitcoin JSON-RPC and (strange?) addresses

In the above blockchain.info link I gave, what are those strange-looking addresses starting with "bc1...", and

Those are bech32 addresses. These are specified in BIP 173

  Is there a way to extract such data from the output of getrawtransaction?

No. The latest release of Bitcoin Core does not have functionality for converting native witness outputs into bech32 addresses. However blockchain.info does so they are displaying those outputs as bech32 addresses. Bech32 functionality in Bitcoin Core will be released in Bitcoin Core 0.15.1 along with segwit wallet functionality.

  If not, how did blockchain.info did it?

Blockchain.info does not use Bitcoin Core. They have their own custom software and it seems that they have implemented bech32.


Is there's anyway to get fee estimation with vbyte instead of KB using "estimatesmartfee" RPC command?

It is of course already using vbytes; anything else doesn't make sense. Almost everywhere Bitcoin Core reports transaction sizes, they're reported in vbytes (for non-segwit transactions, 1 vbyte = 1 byte, so it was a transparent and compatible update).

However, the unit Bitcoin Core uses is "BTC per 1000 vbyte" rather than the currently more common "satoshi per vbyte".

A Bitcoin Core reported feerate of 0.00123456 BTC/kvb corresponds to 123.456 sat/vbyte.


How do I double SHA-256 the header of block #59,500?

take first 160 symbols from https://blockchain.info/block/00000000096af43105123c499521e1d131d172e7e1bf2ed0843290a921f1f6a7?format=hex

should I explain more? :))))

update:

01000000 version

a1c77a081de8e03801563ffb02833fd10c2dbd7fd2228ae7b0ba3b0200000000 prev hash

38805219c8ac7e9a96416d706dc1d8f638b12f46b94dfd1362b5d16cf62e68ff merkle hash

27b80a4c timestamp

5c670f1c bits

8bedfd00 nonce


Why does Binance use USDT instead of USD?

It makes sense to me that they don't offer a USD trading pair, as binance does not have access to the US banking system, much less so to the or a federal reserve account.

How they are able to represent the euro in the first place within their exchange/framework, i don't know. That would mean they would have an account at a EU bank and subsequently at a NCB within the eurozone, which i highly doubt given they operate with and within "anonymous" accounts. (I highly doubt this would be allowed by the ECB and subsequently their commercial bank), If anyone could shed some more light on this and how this would actually work (I fear I might be wrong here.), I'd be extremely interested.

Before thinking you can use USDT as a safe haven, you should note that more often than not, these "stablecoins" are not backed 1:1, or at least not proven to be, and that while they might be stable as of right now, that that is not a guarantee for the future.

USDT in particular lacks audits. A quick google search on the topic will give you a wide range of articles why they're so controversial.

Anyway, to answer your question, yes, USDT is probably the closest to representing the value of an actual dollar, but, as i said, it is NOT an actual dollar, and you should be really careful using them, or preferably; not use them at all.


Is it possible to catch up missing blocks with zeroMQ if script was down for a while?

No, it is not possible to catch up via ZMQ itself. A sequence number is present with each notification so you can detect when you've missed notifications. In those cases, then you can fetch the missing blocks and transactions over the RPC interface.


How do they know which chain is the real one?

The "real" chain is whichever chain a majority consensus of network participants considers to be real.  There isn't exactly a "real" chain; only an "agreed upon" chain.

Bitcoin is an incentive based system, and in the long term, it is in everyone's best interest to use the chain that everyone else is using.  Bitcoin clients use a "longest chain" rule to determine which fork of the chain is the one they (individually) consider to be "real".  Of course, every block on this chain must abide by the rules which that client deems to be the "real" rules.  When different clients disagree on what these rules are, a hard fork occurs.


What are the benifits of using Compressed Bitcoin Addresses rather than Uncompressed addresses if same length?

An address contains a hash of something, usually of the public key. For signature verification, a signature, the signed data and the public key is needed. Since inverting a hash is considered impossible the public key is revealed and embedded in the blockchain every time a 1... address spends an Unspent Output paid to it.
Hashes are of constant length, but the public key saved in the blockchain to spend isn't. There is no special handling code that causes uncompressed public keys to be compressed before they make it to the blockchain either. Hence uncompressed public keys take larger space and their transactions are more expensive.


Hardware wallet without a hardware wallet

Create a seed outside a hardware wallet and then importing it in this latter doesn't make any sense. Hardware wallets have a strong security because the seed is generated by themselves and never revealed outside. I would recommend to wait for your hardware wallet and then generate and transfer your coins on it.

If you know the risk and still want to generate a wallet outside, then you can import it to hardware wallets thanks to the 24 words seed. Make sure your software implements BIP39.

These are the standards implemented by both Trezor and Ledger wallets:

BIP 16 : P2SH serialized script addresses
BIP 32 : hierarchical Deterministic Wallets
BIP 39 : seed mnemonic
BIP 44 : specific wallet structure


Exploring a local copy of the Bitcoin blockchain without running a full node?

This sounds like you'd like to run a full node, which does exactly what you are requesting. You can run a Bitcoin Core full node with wallet services disabled if you want to use it just for blockchain analysis. I'd suggest following along the bitcoin.org guide to running a full node, and take a look at the Bitcoin Core Config Generator for all the different configuration options. You'll need at least 180GB of free HD space, especially if you are going to run the node with the Transaction Index turned on, which you will want for doing fee analysis.


Is there a reason pooled miners should revert to 0.7 due to the fork?

Miners who use a pool don't necessarily even have bitcoind. They use separate mining software (which does not constitute a node, or build blocks or anything of the sort) and the bitcoins they receive are first credited to the pool eWallet, and can then be withdrawn to any wallet.

The pool is the one choosing the blocks and even if the miner's wallet happens to be bitcoind it has no influence on this process. So there is no reason to downgrade.


Ubuntu Linux -- How do I start bitcoind as a service to run automatically?

EDIT: Caveat emptor on Ubuntu distributions from 14.10 and forward - init was chosen over upstart and is being phased in the future. I don't know when that will be done nor what impact it will have on upstart scripts.
Extract from the page RentFree refers to; note that it assumes that you have created a user called bitcoinuser for the sake of security:

For those running ubuntu, you may be familiar with upstart, a replacement for sysvinit style booting (/etc/init.d/*).
Configuration files for upstart are stored under /etc/init/*.conf. I've written the following one for bitcoind:
description "bitcoind"

start on filesystem
stop on runlevel [!2345]
oom score -500
expect fork
respawn
respawn limit 10 60 # 10 times in 60 seconds

script
user=bitcoinuser
home=/home/$user
cmd=$home/bin/bitcoind
pidfile=$home/bitcoind.pid
# Don't change anything below here unless you know what you're doing
[[ -e $pidfile && ! -d "/proc/$(cat $pidfile)" ]] && rm $pidfile
[[ -e $pidfile && "$(cat /proc/$(cat $pidfile)/cmdline)" != $cmd* ]] && rm $pidfile
exec start-stop-daemon --start -c $user --chdir $home --pidfile $pidfile --startas $cmd -b -m
end script

Put the above configuration in /etc/init/bitcoind.conf, then run sudo initctl reload-configuration. To start bitcoind, run sudo start bitcoind. To stop bitcoind, run sudo stop bitcoind.
You'll probably want to change the user, cmd and pidfile to something that matches your configuration, or you can use the following as a template:
/home/bitcoinuser
/home/bitcoinuser/bitcoind.pid
/home/bitcoinuser/bin/bitcoind

Though one user suggests the following correction to the configuration:

home=/home/$user
cmd=/usr/bin/bitcoind
pidfile=$home/.bitcoin/bitcoind.pid

and another suggests setting nice for the process so it doesn't hog the CPU

exec start-stop-daemon --start -c $user --chdir $home --pidfile $pidfile --startas $cmd -b --nicelevel 15 -m


Coinbase purchase bitcoin transaction pending, why is it painfully slow to purchase

Coinbase is a service, your transaction is happening on their internal servers, not the bitcoin network. If you choose to withdraw your bitcoins to an external wallet, that would involve a transaction on the bitcoin network.

So the delay depends entirely on Coinbase, during high volume times I would guess their order fulfilment is slightly slower. Your order will come through though!


click on request on the receive tab to get an address. optionally you can enter a description before clicking on request. the description will be saved in your wallet and will show up on the history tab when you receive money. this helps you keep track of what the money is for.


How do wallets (like jaxx) pair with each other using the mnemonic seed phrase?

You've got everything right. The last step (the one you are referring to) is done by brute force. The wallets just try out many many possibilities until they think they've guessed all the derived privKeys that you actually used. For each possible privKey, the wallet calculates the address and checks whether this address exists on the blockchain ( = there are or were coins on this address).

If you use the same wallet for recovering that also created all the addresses, then the derivation process is obviously the same and the wallet knows exactly how to derive the privKeys, to be sure to "guess" all of them.
There are also standards for how to derive the privKeys:

https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki


Could Bitcoins (or any other blockchain based cryptocurrency) feasibly ever be used for purchases that need to go through fast?

Blockchain technology, at least without accepting central party that controls access to the chain, inherently has slow blocks, or strong centralization incentives.

The reason is that blocks need to propagate much faster than the block interval time. If they don't, miners who are further away from the majority of the hash power are put at a disadvantage.

To explain this intuitively, notice that when miner A creates a block, he can start working immediately on a successor, while another miner B first needs to wait until A's block reaches him. During that time, B works on an outdated chain, and is unlikely to produce a block that ends up being accepted. The closer A and B are located together, and the more trust they have in eachother about not lying about new blocks they produce, the more they start to behave like a single party.

Thus, the ratio of block interval and propagation speed across the network is a means for keeping the advantages of larger miner groups over smaller ones in check.

This does not mean that the bitcoin currency is inappropriate for fast payments. They just require another mechanism than on-blockchain transactions. For example, look at the proposed Lightning network, which allows many small transaction between parties to occur, while only settling the resulting balance on the blockchain. It requires more trust, but has higher performance and convenience, and lower costs.


"Assertion Failed!" when I try to open Bitcoin Wallet

Found out a way to fix the problem - really easy too:

1) Copy bitcoin data files to external hard drive
2) Uninstall Bitcoin application
3) Copy bitcoin data files back to their original location
4) Download and reinstall Bitcoin application.  It finds the old files and everything works perfectly.

Thank you all for your help.
D


How many throws of a dice are necessary to defeat a brute force attack?

Rolling a single die has 6 possible results. A private key is a 256-bit number. But its address involves a 160-bit hash, so that's the most you need to use.  To know how many dice rolls you need to get this much entropy, you need to know when 6^n > 2^160 (because the probability of a certain sequence of n die rolls is 1/6^n). This is equal to ceil(log(2)*160/log(6)) or 62.

So if you roll a die 62 times (or a pair of dice 31 times, etc. - but be sure to count the die separately, and in a consistent way - e.g. do not always write the smaller of the two first, because you'd remove some entropy), and write down the numbers in order (e.g. "132415614..."), you can use that to seed a crypto random number generator that can give you a private key as secure as is possibly useful.

Electrum's seed is 128 bits, and is considered (by those who created and use it, at least) to be secure enough for not just one private key, but all of your private keys. To match that entropy, you need 50 die rolls.


How to build Merkle root from merkle branches?

This would indicate an empty block (no transactions). So only coinbase should be used to construct merkle root. So merkle root = Coinbase

Example block: https://www.blockchain.com/btc/block-index/512049/00000000000000000429a0c4fbe735b2d8b493daedf0207728543f748c262437

(edit: but please verify with others)


You should only need to connect to any of the nodes in the Lightning network and it should take care of learning about the rest of the network. So my suggestion would be to take any node on https://lnmainnet.gaben.win/, look at its details, and if it has a public key and IP associated just connect to that one.


Since the LocalBitcoin wallet doesn't have a private key import function, you can't shorten the number of steps.
You can use Electrum, it's very popular and it has both "import" and "sweep" functions. If you don't want to trust it (I do trust it, unless the computer has malware) you can use it on an airgapped computer.
That's all you need to know, good luck!


How can bitinfocharts.com know the changes in BTC deposited to Binance?

Based on the address the binance gave you, after they sweep the funds into their hotwallet, you can run common-input heuristic on this deposit address (assuming it was swept in with other inputs). The more addresses and sweeps, the better the accuracy and amount of addresses in the final (result) set.
https://en.bitcoin.it/wiki/Privacy#Common-input-ownership_heuristic
Based on the binance hotwallet you can also assume that all addresses that inputs into this hotwallet are deposit addresses.

Having set of all (assumed) addresses of binance you can run basic script to see balances in/out.


Check this page: How soon might I expect to generate a block?

So with the current difficulty  510,929,738, and a 1Ghash/s mining rig (faster than your CPU) you'd do this math:

510929738 * Math.pow(2,32) / Math.pow(10,9) / 60 / 60 / 24 / 365

So to find a block at this difficulty with a 1Ghash mining rig it would take you about 69 years on average.
Good Luck!

PS: Math.pow(2, 32) is simply the JavaScript version of 2^32


why is the growth in the number of bitcoins not convex?

It is decreasing by half every 4 years, just that graph is just not showing it well for this short timeframe.

The dip up until 2010 was due to there only being one or two miners in the entire network, so the maximum number of Bitcoin wasn't produced in that period. The speed of the entire network couldn't keep up with the minimum of 6 blocks an hour which has lowered the total available Bitcoin in that period, though the number overall is just fine.  You can see the sharp decrease in late 2012 when the block reward halving first occurred, which is the start of the downward trend in block reward production.

Currently the network hashrate is increasing so quickly that it's producing more Bitcoin than expected, we'll probably reach the next halving in a little less than the intended 4 year cycle. That's not a negative effect in itself though, it just means the network is increasingly secure month on month. There's a similar hump between June and July of 2011, when GPU mining was publicly introduced.


How do you perform double-SHA-256 encoding?

You're hashing the hexadecimal representation of the first hash. You need to hash the actual hash -- the binary data that the hex represents.

Try this:

$ echo -n hello |openssl dgst -sha256 -binary |openssl dgst -sha256


Hedging against the bubble popping - where's the leverage?

Like @David Ogren suggested, you are just supposed to sell part of those coins.

Dunno why are you trying to make it so much more complicated.


How much time in average does it take for an simple PC to create block?

The answer is constantly changing, but this is something you can calculate yourself.

Look up the current Bitcoin difficulty value.  Right now it is 460,769,358,091.  Let's use scientific notation: 4.6e11.
The difficulty determines the average number of hashes needed to mine one block.  A minimum difficulty of 1 corresponds to 2^32 = 4.3e9 hashes, so we need an average of 4.6e11 * 4.3e9 = 2.0e21 hashes to mine a block.  (More precisely, each hash performed has a probability of 1 in 2.0e21 of successfully creating a block.)
Look up the approximate hash rate for the hardware you have in mind.  For CPUs and GPUs there is a table here; ASIC devices can be found here.  According to that table, a Core i7 2600 CPU can do 23.9 MHash per second, or 2.3e7 hashes per second.  Maybe you are starting to see the problem.
2.0e21 / 2.3e7 = 8.7e13.  That is the average number of seconds your computer will need to mine one block.  It is about 2.7 million years.

This should give you a sense as to why all Bitcoin mining is now done with specialized ASIC hardware, which is many orders of magnitude faster and more energy-efficient.


In the ASIC-age, is it worth starting mining Bitcoin at home?

Generally, it's not worth your time and effort to mine at home! (Some exceptions may apply.)

Age of ASIC mining

CPU mining has been unprofitable since 2011, GPU mining just slightly later.

Today, ASICs rule mining. The Bitcoin network has more than 1.7 Ehash/s (Oct 2016) now which is 1,700,000,000,000 Mhash/s. Your      graphics card will be running full blast to churn out a few hundred Mhash/s, your CPU maybe a few dozen.

With CPU or GPU you will never collect a sufficient balance with a mining pool that you could even get paid out. It's a waste of time, even if you don't pay for power.

Mining has gone big scale

Meanwhile, ASIC mining has gone industrial. Corporations are building mining centers in regions with very cheap power, and filling them with millions of USD worth of ASIC miners. Greater mining power in one hand  does have some slight advantages which adds to their more efficient processes.

Finally, ASIC miners have been catching up quickly technologywise: Every few months new chips get announced moving the scale down a few more nm. Currently, we are reaching 16nm technology (Oct 2016), which is already pretty close to the general state of the art. The problem with that is that every step of miniaturization comes with a leap in power efficiency, quickly obsoleting older generations of ASICs. Chances are that your        investment will outdate before it pays for itself – even when you are just looking at cost of acquisition and have no cost of power.

Mining profits tend to zero

The mining market tends to reach an equilibrium: While it is very profitable to mine, there is room for investments. The additional mining power increases the difficulty for all which in turn reduces the profitability. When the difficulty rises, it drives out the least cost efficient mining operations, in turn increasing the profitability of the remaining miners. If you're not in a particularly advantageous position, you will be quickly pushed out of the market.

Also see: Why does mining profitability tend towards zero?

If you're not paying for your power, someone else is

Anyway, if you're "not paying for your power", because it's included in rent (e.g. in a dormitory), you're either privatizing profits by socializing costs, i.e. stealing from your neighbors, or you'll be paying   for it next year when your landlord increases your rent to cover the higher power bill.

If you produce a power surplus or use the ASIC to replace electric heating, hey, you might be one of that exceptions I mentioned going in.

There might be some altcoins that can still be profitably CPU/GPU mined and traded for Bitcoin thereafter, but I am not sure whether even they are worth it when you factor in your time investment.

If you have understood all of the above, please feel free to check out

How much Bitcoin will I mine right now with hardware X?
How can I start mining Bitcoin?


Can you buy bitcoins as a Canadian without a bank account?

There's a wiki page about buying Bitcoins with a credit card. It seems the ideal options for you would be Brawker or MeetPays. But whatever method you decide to use, don't forget that Bitcoin is not anonymous (by default), that's a common myth.


Help - Running R9 290x graphics card headless in Linux

I had the same issue with my R290 cards and was able to have them work after initialiazing xinit:

Create an xinit file:

sudo vi /etc/init.d/xinit

Put inside:

#!/bin/bash
# standard functions library
. /lib/lsb/init-functions
# Start the xinit
start() {
        # Start xinit on background and redirect stdout and stderr to log file
        echo "Starting xinit"
        xinit &> /var/log/xinit.log &
}
# Restart the xinit
stop() {
        echo "Stopping xinit"
        killall xinit
}
### main logic ###
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        status xinit
        ;;
  restart|reload|condrestart)
        stop
        start
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac
exit 0
# end of file

ESC :wq  ==> to save and quit vi editor

Then make this script executable and set it up for automatic startup.

sudo chmod +x /etc/init.d/xinit
sudo update-rc.d xinit defaults 90

export DISPLAY=:0
echo export DISPLAY=:0 >> ~/.bashrc

sudo reboot

It worked for me!

BTC: 1KsRn32jBwA21fLyVMdVWdGLxAa3vo82Zy

LTC: LQC2cfKFNri8AHeME6QQqVeB4BD6tQEdDE

P.S. xinit setup taken from http://infi.wikidot.com/blog:1


Can op codes be used instead of signatures?

Existing signature schemes in Bitcoin are already implemented as opcodes (OP_CHECKSIG and OP_CHECKMULTISIG in particular), so this question's formulation seems a bit off.

If you don't mind a transaction whose outputs can be taken by anyone, this is trivial - you can just create an output with a script that does not use any signature checking opcodes.

Perhaps what you want to ask is Is there a way to create secure transactions without using any of the explicit digital signature opcodes?.

The answer to that is almost certainly no. You would effectively need to implement a digital signature scheme by hand, rather than relying on the provided ones. Digital signature schemes are remarkably complicated, and likely far beyond what is possible inside Bitcoin's current scripting language.


special block version or is my data corrupt?

That block file is corrupted. You will have to delete blk00622.dat and any higher numbered blk*.dat file and rev00622.dat and any higher numbered rev*.dat file. Then you will need to reindex. This should fix the issue as the corrupted blocks will be redownloaded.


Why lightweight nodes are less secure?

A lightweight node is less secure because it doesn't store its own copy of the entire blockchain.

This means it cannot verify for itself the integrity of incoming blocks with complete certainty. It generally has to rely on the integrity of an external server for at least some starting block. This is the kind of trust of third parties that Satoshi Nakamoto was trying to avoid when creating Bitcoin.

  and the next question is

One question per question. Please use the "Ask Question" button at top right to ask a new question. You can include a link back to this question if it helps clarify your next question.


How to use -txindex to enable blockchain transaction queries?

use

txindex = 1

in you bitcoin.conf file and restart daemon with -reindex flag if you are building it for the first time, it might take a while but after txindex is defined you can get data for any transaction in blockchain no matter if its related to your wallet or not.

Alternetivly you can start your daemon with

 bitcoind -daemon -txindex=1 -reindex=1

Either way it functions the same


In many ways, it is just coincidental that GPUs are going at hashing. It doesn't surprise me that some GPU engines are a better fit than others. A particular GPU might be very good at some types of mathematical operations (or rendering, for that matter) but might not be particularly good for hashing.
This is discussed in some detail on the bitcoin.it wiki:

Firstly, AMD designs GPUs with many simple ALUs/shaders (VLIW design) that run at a relatively low frequency clock (typically 1120-3200 ALUs at 625-900 MHz), whereas Nvidia's microarchitecture consists of fewer more complex ALUs and tries to compensate with a higher shader clock (typically 448-1024 ALUs at 1150-1544 MHz). Because of this VLIW vs. non-VLIW difference, Nvidia uses up more square millimeters of die space per ALU, hence can pack fewer of them per chip, and they hit the frequency wall sooner than AMD which prevents them from increasing the clock high enough to match or surpass AMD's performance. This translates to a raw ALU performance advantage for AMD:

AMD Radeon HD 6990: 3072 ALUs x 830 MHz = 2550 billion 32-bit instruction per second
( Nvidia GTX 590: 1024 ALUs x 1214 MHz = 1243 billion 32-bit instruction per second

This approximate 2x-3x performance difference exists across the entire range of AMD and Nvidia GPUs. It is very visible in all ALU-bound GPGPU workloads such as Bitcoin, password bruteforcers, etc.
Secondly, another difference favoring Bitcoin mining on AMD GPUs instead of Nvidia's is that the mining algorithm is based on SHA-256, which makes heavy use of the 32-bit integer right rotate operation. This operation can be implemented as a single hardware instruction on AMD GPUs (BIT_ALIGN_INT), but requires three separate hardware instructions to be emulated on Nvidia GPUs (2 shifts + 1 add). ?This alone gives AMD another 1.7x performance advantage (~1900 instructions instead of ~3250 to execute the SHA-256 compression function).
Combined together, these 2 factors make AMD GPUs overall 3x-5x faster when mining Bitcoins.

This is also discussed in a bitcoin talk thread.


How to know Block height when a transaction entered Mempool?

Bitcoin Core has a getmempoolentry command. This takes a txid and returns information about that transaction's mempool status. This includes height which is the block height when transaction entered pool.


download the bitcoin chain begining from a certain date

I am gonna need to use prude mod and began the download of the chain starting from march 2018 as recquired by lnd,
my question is which bitcoin client is able to do that and how to configure it for this procedure ?

I don’t believe any client can do this: how will your node know if a UTXO from before March 2018 was valid if it hast verified the full history of the chain?
When a node is bootstrapped, it will work through the blockchain’s history to build a UTXO set. Without being able to build and verify this UTXO set from scratch, there is no way to know that a UTXO is valid (without trusting someone else). For example, if someone opened a channel with your node, by consuming a UTXO from 2017, how would your node be able to determine the validity of that UTXO?
Even for a neutrino-serving node like btcd, the node still needs to have verified the entire history, in order to serve the LN node valid data.


Bitcoin ATM paid out to a phone number, how can the funds be retrieved?

it seems like a wallet address was generated for her

This seems most likely to me. An ATM should not allow the destination/receiving address to be empty or to contain something that is not a valid bitcoin-address (e.g. a phone number would be rejected)

A phone number might be requested for an online custodial wallet service with two-factor authentication (2FA) - if so you'd need to find out the URL of the service, and the corresponding username and password or other credentials.

If your friend doesn't have a printed receipt with some details on it, it is likely that the money is now forever inaccessible.

I would

try to find a printed receipt
contact the ATM owner (although I would not expect them to be able to help)
visit the ATM with your friend and try to recreate what happened with the minimum possible amount of money as a test.


How would I go about exploring Bitcoin's entire block chain?

The easiest way to look at the transactions in any arbitrary block would be with a block explorer.

As of the instant I'm answering this question, the newest block is block #456238, so you can peek at any block by creating an address for a web block explorer as follows (Blockchain.info for illustrative purposes):

https://blockchain.info/block-height/0

https://blockchain.info/block-height/456238


Creating a NXT/Ardor transaction using the NXT api via post

Sure, connect to any public node or your local node using http://localhost:7876/test and use the resulting API test page as example.


Is there a way to estimate the price based on the blockchain?

I wrote a bitcoin price theory is about a correlation of number of bitcoin addresses
(from blockchain) and the bitcoin price, with a law of networking use like the metcalfe law.

here I posted my study about your question

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


cgminer is a command-line software.

Open a Terminal and change the working directory to where you have your cgminer executable with the cd command. For example, if you have it on the Desktop you have to use the following command: cd ~/Desktop (where ~ indicates your home directory).

Then, if necessary, mark it as an executable file with the chmod +x cgminer command and finally run it with the ./cgminer command. Note that you will probably need to run it as the root user, so you probably want to run this command instead: sudo cgminer.

You can also specify command line options. For example, if your pool URL is http://foobarpool.net:3333, your username is qwertie.1 and your password is 1234 you can run cgminer with the following command so it is preconfigured and will start working right away: sudo cgminer -o http://foobarpool.net:3333 -u qwertie.1 -p 1234.

You can also specify lots of options for the GPU, fallback mining pools and other things. For a complete list, use this command: cgminer --help.


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


Addendum: It looks like the coins have been found; just quoting the relevant solution from the external thread so we have a complete answer on record. Long story short, the problem was as we suspected: the paper wallet did not contain all of the change addresses from the 5btc of transactions that had occured since tge import. Simple fix:

  I started the client with /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -salvagewallet. It's still syncing with the network, but it looks promising as it's now showing a +4.9315 balance!

Ok, I'm beginning to piece together what happened now.

At least according to your blockchain links, you initially received 10 BTC via 3 transactions, at the 1Fr3p address then spent 5 on 17 april. So that particular address only had 5 remaining at the time of the import to coinbase.
When you import rather than send, the coins will still show in both wallets;  if you send them from the old one after that this will not update in the new wallet because of change addresses.  Importing != spending.
You will additionally need to import the change addresses that have been created since using bitcoin-qt to coinbase for everything to sync correctly.  Check out this thread.
As far as fixing the crazy transaction, I'm not sure what to do there.  Hopefully when you finish importing everything it will manage to work itself out in the client?  Don't send anything else from the old wallet again--once you can use  the coins  available in the coinbase wallet, send from there only.
If you want to use qt client again, create a new wallet for all transactions moving forward.

update
What do you know about these transactions from your link in the comments?  Your client is only showing the -.01 portion of those tx but the remainder seems to be what's missing...


found out the issue,I'm running bitcoin in testnet while I put server.pem and server.cert in the data dir not under the "testnet3".As I moved the two files,things be OK.


BlockChain scalability: How does BlockChain process multiple parallel transactions?

You should probably read up a bit more, but here's some help:

  miners in the peer to peer network will (individually?) start solving for the next valid hash in the block chain. ( does the peer network use the combined processing power to solve together, or do nodes solve individually independent of each other?)

Nowadays miners work together in mining pools.  These are not part of the actual protocol, but is just the way the mining ecosystem has evolved.  As far as the Bitcoin protocol is concerned, you can look at an entire mining pool as an individual miner.  Each pool is responsible for trying to make their nodes work in parallel.

  Regardless of this, the peer network will be solving for the next hash in the blockchain which will verify 1 transaction

This is where you are wrong.  The hash is for a block of transactions, not an individual transaction.  For many reasons, it is advantageous to do the proof of work on blocks rather than transactions.  See this question for more explanation on that.

I hope this helps.


RBF Tools by Peter Todd

This page contains

  ..tools to test out replace-by-fee functionality. You'll need a local
  node with the replace-by-fee patch.

E.g.
To double spend ./double-spend.py <address> <amount>

To just increase fee ./bump-fee.py <txid> etc.


Even though the comments were pretty clear about, "don't even try this", you seem insistent.

Mining Power is measured in Gh/s, or Giga-Hashes per second, which means how many Billion hashes can a computer try every second.

The mainstream ASIC processor, AntMiner S9, can do about 13 Th/s (13 Terra-hashes, or 13,000 Gh/s).

A good graphics card GPU can do about 1 Gh/s.

So you would need on the order of 13,000 graphics cards to come close to a single ASIC processor.

Since the S9 has a breakeven point around 1 year, it would take your PCs about 13,000 years to make enough money to buy a single S9, and the PCs would be far more expensive upfront, and use far more electricity along the way.

Bluntly put, if you really really focused with PC mining, you'd be extremely lucky to make about $3 a year.

References:

Is Gpu mining still an option?

https://bitmain-alliance.com/product/antminer-s9/?gclid=Cj0KCQiAuZXQBRDKARIsAMwpUeTtoNrXLyaRXqeHuVyaoEj4jeGUrx4zyJGeVYQpTUcvHllr41MKvb8aAj1iEALw_wcB

https://www.cryptocompare.com/mining/calculator/btc?HashingPower=4730&HashingUnit=GH%2Fs&PowerConsumption=1293&CostPerkWh=0.12

https://99bitcoins.com/2016-bitcoin-mining-hardware-comparison/


storing bitcoin's database directory on an external drive?

Bitcoind requires your wallet file to be in the same location as the rest of the files, so I think what you want to do will be difficult, as it might require editing the source/recompiling

However, you can just store your wallet on the external drive too.

You can encrypt the wallet if you don't want it to fall in the wrong hands

You can use the backupwallet command to back it up if you are affraid of the quality of your external drive...


Can signature be re-used to cash out everything in the address?

When you sign the transaction with your private key, you include the hash of the entire transaction data as a message. This means the signature which is generated is specific to that transaction itself and any modification to the transaction will render the signature invalid. In this case, the user who has signed the transaction has already specified the address to which the bitcoins have to be sent. Any modification in the address will change the message digest, thus invalidating the signature.

Moreover, Bitcoin operates on an UTXO model rather than an account/address based model. Everytime you send bitcoins you consume previously unspent outputs in its entirety and create new unspent outputs. For example, let us say you have 1BTC UTXO. When you want to spend for a 0.1 BTC coffee, you will consume the entire 1 BTC UTXO, send 0.1 BTC to the coffee shop and 0.9 BTC back to yourself. This 0.9 BTC output is different from the 1 BTC output that you controlled previously.

In a transaction, these unspent outputs are specified in the transaction with the identifiers: txid and vout. After the user's transaction gets confirmed, the txid which was referenced in the previous transaction no longer remains unspent. Thus, it is not possible to re-use the same signature even if you are sending to the same addresses again.


Bitcoin cash wallet with ability to generate new addresses

The wallet I use, ElectronCash, has the ability to create multiple adresses. Bitcoin and Bitcoin Cash use the same adresses and private key format, so you can use your Bitcoin adresses as Bitcoin Cash adresses.

Bitcoin Cash now also uses the bech32 address format.


How do I use the RPC command "decodescript"?

You didn't copy the full script from blockchain.info, you copied half of the already decoded script. The part you copied is the signature, but the public key (the other part) is also part of the script. Even if you had both, though, it's still not the right data to pass to decode script, because the script has already been decoded. The hex that should be passed to the getrawtransaction call can be gotten by looking at the result of:

getrawtransaction 2c7b5cede0ab477800c407526ea98de9c89e80e53435dc786479be15970cc0d7 1

But you will just get the same thing as what blockchain.info already has up on their site.

And the "p2sh" value is the address that would be made by using the script passed to the RPC call as the redeemScript. I don't think this is what you're looking for at all, so you can pretty safely ignore it.


Decode blocks received and Store in another file for analyzing

#include <QTimer>
#include <QFile>

#include "BlockChain.h"

BlockChain::BlockChain ( const int start, QObject* parent ) : QFile ( parent ), blkFile ( start + 1 )
{
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}
//--------------------------------------------------------------
void BlockChain::start ( )
{
  setFileName ( blkFileName ( blkFile++ ) );
  if ( !open ( QIODevice::ReadOnly ) )
  {
    _trace ( QString ( "cant open [%1]" ).arg ( fileName ( ) ) );
    getParent ( ).block ( QByteArray ( ) ); // finish signal
    deleteLater ( );
  }
  else
  {
    _trace ( QString ( "processing [%1]" ).arg ( fileName ( ) ) );
    QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
  }
}
//--------------------------------------------------------------
void BlockChain::next ( )
{
  bool lock ( true );
  if ( pos ( ) < size ( ) )
  {
    quint32 magic;
    quint32 size ( read ( (char*)&magic, 4 ) );
    xassert ( ( ( magic == MAGIC_ID ) || !magic ) && ( size == 4 ) );
    if ( magic )
    {
      read ( (char*)&size, 4 );
      xassert ( size > HEADER_SIZE && size <= MAX_BLOCK_SIZE );
      getParent ( ).block ( read ( size ) ); // process data
      QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
      return;
    }
    else
      lock = false;
  }
  close ( );
  getParent ( ).doneFile ( lock, blkFile - 1 );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}
//--------------------------------------------------------------
const QString BlockChain::blkFileName ( const int i )
{
  return
    ( i < 10 ) ? QString ( DATA_ROOT "\\blk0000%1.dat" ).arg ( i ) :
    ( i < 100 ) ? QString ( DATA_ROOT "\\blk000%1.dat" ).arg ( i ) :
    QString ( DATA_ROOT "\\blk00%1.dat" ).arg ( i );
}


Does miner's reward get added to blockchain

The miner's reward is verified by every node (you referred to "someone else"). It gets rejected if invalid conditions are contained. The keyword here is "coinbase transaction", and it needs to follow the rules mentioned in the book. This coinbase tx goes into the ledger, if it follows the rules.

Source


is it possible to retrieve some block transactions using bitcoin-core?

Yes. Use the getblockhash and getblock commands. You would do:

getblockhash 517716

and this will return you the block hash for block 517716. Then you can do

getblock <hash> 2

where <hash> is the hash from getblockhash. This will give you the full block details with the full details of all of the transactions in the block. If you just want txids, change the 2 to a 1.

Note that this only works if you are not in pruned mode. If you are pruning, there is no guarantee that you still have the block.


What OP code can I use in the scripting system to make a smart contract that acts similar to a lottery

You might be able to combine a hash lock with a conditional payout.

Here's a somewhat simplified example that shows how to make a payout depend on knowledge of a secret. Bob makes a bet with Alice that she can't guess Bob's secret before a deadline. Alice proves she knows the secret by publishing the preimage to its hash value, which Bob publishes. Alice and Bob each contribute one bitcoin. The winner receives two bitcoin. If Bob doesn't reveal the secret after the deadline, Alice takes all the money.

There are two one-bitcoin inputs, signed respectively by Alice and Bob.

There is one two-bitcoin output. It is protected by a nested conditional challenge script that looks something like this:

IF
  // Alice spends with secret before deadline
  OP_HASH256 <hash> OP_EQUALVERIFY <Alice pubkey> OP_CHECKSIG
ELSE
  // deadline has expired
  <deadline> OP_CHECKLOCKTIMEVERIFY OP_DROP

  IF
    // Bob spends by revealing the secret
    OP_HASH256 <hash> OP_EQUALVERIFY <Bob pubkey> OP_CHECKSIG
  ELSE
    // Alice spends if Bob refuses to publish the secret
    <Alice pubkey> OP_CHECKSIG
  ENDIF
ENDIF

To spend the output before the deadline, Alice uses this response script:

<Alice signature> <secret> <1>

After the deadline, Bob uses this response script:

<0> <Bob signature> <secret> <1> <0>

If Bob fails to spend the output after the deadline (revealing the secret), Alice takes all the money with this response script:

<0> <Alice signature> <0> <0>

There's a problem with this approach, though. If Alice doesn't guess the secret and Bob publishes it, Alice can use the secret to make her own transaction claiming the output. This sets up a race condition in which Alice and Bob each have pending transactions trying to spend the output.

One way to fix this problem would be to give Bob a grace period immediately after the deadline (say, one day). During the grace period, Alice would be unable to spend, but Bob could.


Migrate from blockchain.info to bitcoin-qt

Login to your blockchain.info wallet
Select Import/Export
Select Export Unencrypted
Select Bitcoin-Qt Format from the drop-down list

You'll then see information that look like this:

"priv":"5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS"

Ignore the other information, what you're looking for are your private keys that look like this: 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS

Then just follow Rick's instructions to import each of your private keys into the Bitcoin-Qt client:

  Run Bitcoin-QT
  Select Help (to the right of Settings)
  Select Debug Window
  Select Console
  Next to the > input box type importprivkey <bitcoinprivkey>

  Example: importprivkey 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS


HD is really about back-ups and wallet recovery, a multisig address can be created from any public keys regardless how/where they were generated. Heck you could use the same public key 3 times, although I wouldn't recommend it I'm just trying to prove a point.
To answer your exact questions:

How does the generation of the other 2 Master Keys happen?

Do you want 2 more master keys, or do you just think you need them? Additional master seeds are not necessary, but if you want more master keys then create additional HD seeds.

What do these keys share?

The master keys? They shouldn't share anything, again not relevant to creating a multisig address.

When new private keys are generated by the user are new keys derived
also on the server?

Private keys are not needed to create a multisig address, just the public keys. If you only want one HD seed to back-up, then use different accounts for each key pair. By accounts I'm referring to the derivation path, for example Account 1 Index 0: m/0/0/0/0, Account 2 Index 0: m/0/0/1/0, Account 3 Index 0: m/0/0/2/0, this would produce 3 key pairs, all with an index of 0 and the public key of each would be used to create the multisig address.


What happened to the bootstrap.dat provided by bitcoin.org?

As user Bitcoin has already pointed out, using a bootstrap.dat is no longer recommended—you can see the release notes for the new faster-synchronization feature here.

As a result, the bootstrap.dat torrent links were removed from bitcoin.org after a short discussion.

The bootstrap.dat file is still available here on the bitcointalk.org forum, and jgarzik has indicated that he will continue to occasionally update it "for academic research and development purposes."

Another alternative is the version which has been maintained by Armory Technologies, available here. At the time of this writing, it is more up-to-date than jgarzik's bootstrap.dat, however it's not clear if it will receive any future updates.


Volume in the Charts is different than what gets returned from the API's

It's not clear which API call that you are using so I'll give my two ideas on what the problem might be:

If you are using the "getmarketsummary" API call and calling that
every minute then you will get wrong data because this is based on
24-hours. In my opinion, this is a useless feature.
If you are getting the market trades and then calculating the OHLCV
value in 1-minute periods, and those values don't match up with the
Bittrex candle charts then you are probably seeing the 2 to 4 minute
delay that Bittrex has. I use a service (ClueDex) that removes
that delay and I can literally get 1-minute OHLCV candle data as
soon as the minute closes.


Is it doable to supplant the current Bitcoin Core implementation with another rewritten in a different language?

There are many implementations of the Bitcoin protocol written in other languages, e.g., Bcoin in JavaScript, btcd in Go, bitcoin-s in Scala, etc.
Bitcoin Core is widely considered as the "reference implementation" and it is certainly the most widely used implementation on the network. Without a written specification, the authoritative resource, if consensus diverges between implementations, would generally be considered the Bitcoin Core codebase.
In terms of Rust, there is a Bitcoin library called rust-bitcoin, but as it says in the rust-bitcoin README:

This library must not be used for consensus code (i.e. fully validating blockchain data). It technically supports doing this, but doing so is very ill-advised because there are many deviations, known and unknown, between this library and the Bitcoin Core reference implementation. In a consensus based cryptocurrency such as Bitcoin it is critical that all parties are using the same rules to validate data, and this library is simply unable to implement the same rules as Core.

Given the complexity of both C++ and Rust, it is unlikely that this will ever be fixed, and there are no plans to do so. Of course, patches to fix specific consensus incompatibilities are welcome.

There would be two possible ways a Rust implementation could "supplant" the C++ Bitcoin Core implementation (assuming supplanting is a healthy goal which is disputed).
One would be more and more users running a full node written in Rust, perhaps based on rust-bitcoin, until it became the most widely run implementation on the network. Arguably this would be a path to supplanting Bitcoin Core as the "reference implementation." (Some would argue that Bitcoin Core is the reference implementation because it is based on Satoshi's original client and a new implementation should never be considered the "reference implementation.")
The alternative would be Rust code is introduced into Bitcoin Core, gradually replacing the C++ code in Bitcoin Core. The latter has been discussed to a greater extent than the former although if this was to ever happen it would be a long term project.
There are arguments against introducing Rust code to the Bitcoin Core codebase and they were discussed in this Sydney Socratic Seminar in May 2020. With permission I include this quote from Rusty Russell:

I really like Rust. It is going from strength to strength and it has got definite merit. But you have got an existing expertise who have tooled up in a certain language. Some of that is self selected but whether that is true or not they exist. Now you are asking people to learn two languages. If you want to broadly read the codebase you have to know two languages and that is a significant burden. Perhaps in five years time when Rust is perhaps an obvious successor to C++ then that intersection… Arguing that we will get more contributors for Rust is probably not true. You might get some different contributors but C++ is pretty well known now. There is the sexy argument. “Work on this, it is in Rust” Unfortunately that will become less compelling too over time. As Rust gets bigger and more projects are using it and there are other cool things you could be doing with Rust anyway. It would be better to do stuff in Rust as far as security. I am cautiously hopeful that the size of bitcoind is going down not up. Stuff should be farmed out to the wallet etc with better RPCs and better library calls so it is not this monolithic project anymore. The argument that we are going to be introducing all these security holes if we don’t use Rust is probably weaker. As you said the last thing that will change is the consensus code. That said I like projects that stick to two languages. It is really common to have projects where you have to know multiple languages to deal with them. Working around the edges and reworking some of the tooling in Rust, building up those skills slowly is definitely the way forward. It will take longer than you want and you hope but it is a pretty clear direction to head in. But head in in terms of a decade we will be talking about finally rewriting the core in Rust. It is not going to happen overnight.

As Prayank says in an above comment, Bitcoin Core functional tests (not unit tests; they are in C++) are written in Python. So you already need to know C++ and Python to contribute to and review the entire Core codebase. If Rust was introduced that would be introducing a third language.


How do you get Sibling Hashed Values in a Merkle Proof?

But the Merkle Root is not enough to prove a transaction is in a block. All the sibling-values up the Merkle Tree are needed. Where do these values come from if they aren't already stored?

Any full node that has a complete copy of the block can construct a merkle proof that proves a requested transaction identifier (txid) connects to the merkle root in a block header.  Here's an animated graphic showing how Bitcoin Core constructs a merkle proof:

For the txid (H5) for transaction 5, a list of hashes necessary to make the proof plus is created along with a list of flags telling the software evaluating the proof which side of each branch the would find the hash.

The lightweight client evaluating the proof uses those flags and hashes to prove the txid connects to the merkle root like this:

For more information, you may wish to read about the peer-to-peer network protocol message merkleblock in the BtcInformation.org Developer Reference, which includes these illustrations.


Matching pushpool difficulty with stratum's

This is how you change the difficulty in Stratum:

go to mining/subscription.py

change

self.connection_ref().rpc('mining.set_difficulty', [16,], is_notification=True)

to

self.connection_ref().rpc('mining.set_difficulty', [32,], is_notification=True)

That will set the difficulty to 32 - or change to whatever value you want.


How do I determine the value of new altcoins?

The price is found when offer and bid intersect. Exchanges are platforms that facilitate the management and visibility of these, but less efficient markets work as well.

The price is what you can get for it in exchange. You cannot dictate the price except by providing your own offers/bids.


No. That's a printf statement, so you will only prevent the printing, not the actual destruction.


If you can verify that Phoenix is running the code that you expect - the open source eclair implementation of the Lightning Network and Phoenix wallet - then they will not be able to use their node to "say that you're cheating". This is because they do not have signatures for your unique commitment transaction, so there's no chance that they can broadcast your commitment and then claim the penalty for themselves.
More generally, mobile wallets that depend on their channel peer for blocks could theoretically cheat their peers by broadcasting old state and then withholding blocks until the time that your node has to claim the penalty output. Phoenix has an option to connect to your own electrum server, which would protect you against this (unlikely) attack if you chose to enable it.


Why does BIP44 use non-hardened paths at all?

Imagine you have a website where you want to sell things. You need the website to be able to generate addresses, but you don't want it to be able to spend from them.

Well, you can give the website an account-level extended public key, and it can generate the non-hardened addresses you need from that. You wouldn't be able to create hardened addresses; you'd need the account private key to make new hardened addresses.

// you now know all my addresses I could derive from hardened. Do you know any
// private keys except for the one I explicitly shared a line before?

No. I know a private key, but I can't work out the parent key or any siblings.

// in difference to the hardened case, you would now learn about nonHardened but
// also (once again) about hardened? What could you actually learn?

Even though this key isn't hardened, I don't know the chain code of the parent key, so I can't compromise sibling keys or even associate that key with any of its siblings.

// would this line leak any information that wasn't already leaked in the last
// block?

Nope. However, if you also exposed

wallet.derive("m").xpubkey

then I'd have enough information to compromise your wallet.


Recipient calculation in verifyTransactionBytes for Ardor

You need to either convert data.recipient from RS format to numeric format or convert transaction.recipient from numeric format to RS format using NRS.convertNumericToRSAccountFormat(id)


There is a Bitcoin wallet extension for Chrome. It's apparently used by 1500 people and has 3.5 stars average review. Still, I would not trust this extension without first auditing its source code. I cannot find its code on its author's Github profile.

CoinSpace is a web-based Bitcoin wallet. It's not exactly an extension but if you understand what Metamask does you'll see that it isn't really different.

Metamask loads up an Ethereum javascript library and offers a front-end to it using HTML. This is exactly what other similar wallets do, e.g. myetherwallet.

Brave Browser used to have a Metamask-like wallet for Bitcoin. I don't know what happened to the code when they moved to BAT tokens but it should be out there. It was basically a Bitcoin wallet in a Chrome extension, so the javascript for Bitcoin functions could probably be refactored out of the extension.


When a miner in a pool finds a valid block, the pool receives a reward (currently ~50 BTC) in a special generation transaction in the block. The address receiving the generation reward in a given block is known, and pools publish statistics on which blocks they found (and even if not, the miner who found it can in theory know which blocks he himself found if his mining software keeps a record of it), so the generation rewards can be tracked (to the same extent that any other Bitcoin transaction can be tracked).

The mathematical operation done when mining is calculating SHA-256 hashes of variants of a block header. You can learn more about mining for example at What exactly is mining?


How to make Bitcoin-Qt or other client run off of a flash drive (Mac)

Somebody posted a portable client, but I don't trust them, so I'll show you how to make your own.
Windows guide

Download the windows .zip from bitcoin.org

Unpack it. Go into that directory.

Make a file called launch.txt
Put this in it:
 start bitcoin-qt.exe -datadir=data

Rename it to launch.bat

Make a folder called data

It should look like this. Double-click launch.bat to start it. If files show up in the data folder you made, then you've done things correctly.
Macintosh guide
Download the Mac .dmg from bitcoin.org
Find the Bitcoin-Qt.app file, and copy it to to your flash drive.
Go to Launchpad, type in 'terminal'. Hit enter.
When the terminal comes up, type:
cd /path/to/flash/drive
mkdir data
cd Bitcoin-Qt.app/Content/MacOS
nano start.sh; chmod +x start.sh

Type in:
#!/bin/bash
dir1=$(cd "$(dirname "$0")"; pwd)
dir=`echo $dir1 | sed 's/"/\\"/g' | tr -d '\n'`
data="$dir/../../data"
"$dir"/bitcoin -datadir="$data"

Now hit Ctrl-O, enter, Ctrl-X. You should be back at the terminal.
cd ..
nano Info.plist

Find the lines that look like this:
    <key>CFBundleExecutable</key>
    <string>Bitcoin-Qt</string>

Change it to:
    <key>CFBundleExecutable</key>
    <string>start.sh</string>

Now hit Ctrl-O, enter, Ctrl-X. You should be back at the terminal. Now we just need to give it a better name.
cd ../..
mv Bitcoin-Qt.app BitcoinPortable.app

Try running your BitcoinPortable.app. If you see files show up in the data directory next to it, then you've done things correctly!
Thanks to Pygy for the script
Note: I don't have a Mac, so this is untested.


Fees for bitcoind sendmany, limits for number of end addresses

You can calculate your transaction size before sending the transaction. Here's some more info on that:

How to calculate transaction size before sending

A single transaction isn't limited to how many outputs it has, rather, there are some limits to how big a block is. You can read more here:

How many different destinations can a single transaction have?

EDIT:
After calculating the size, you can further calculate fees by using this method (it takes into account some code in main.h):

What is the exact formula for calculating transaction fees?


How do Bitcoin and Colored Coin react to malformed transactions?

I think you are correct.
It is perfectly reasonable that a colored-coins transaction is malformed while its bitcoin-level data is correct.

Indeed, most colored-coins transactions are legal bitcoin transaction in any case. Think of wallets like Colu, which cover every transaction for you. It's very unlikely that something done automatically comes out malformed.

Anyway, I wouldn't say that colored-coin nodes "forget" this transaction.
They will just consider it as a non-colored transaction or an invalid colored-transaction, depending on the error.
However, since it is a valid bitcoin transaction, it will be included in the blockchain (which is the same for both colored and non-colored nodes);
and then "visible" to all nodes.

Generally speaking, I would say it will be simply considered as the other (non-colored) bitcoin transactions.


Will this Transaction still arrive or was it stolen?

The transaction ae6f689cb77a5eceea9eed5a91ce51f940fef2b8832946e747d0d0d788c3d9b3 was confirmed in block 594768, paying a total of 0.00520707 BTC to the bitcoin address 37wefhkU2JDzQWJpmkTAB73AiQxBRXFQe.

This transaction is confirmed, and at this point has several days worth of blocks on top of it, so it can definitely be considered immutable at this point.

If someone asked you to pay some BTC to this address, and now is pretending that it "didn't arrive", "was stolen", "can't be accessed without some payment", etc, then you should be extremely wary of dealing with that individual in the future. This 37wefhkU2JDzQWJpmkTAB73AiQxBRXFQe address did receive payment, it is not possible that it was "stolen before being delivered" or something like that.


How automatically to forward bitcoins from one address to another?

You may use /etc/crontab on your Ubuntu:

* * * * * root /bin/bash /usr/local/bin/bitcoin_resender

And script shall looks like:

$ cat /usr/local/bin/bitcoin_resender
#!/bin/bash
if [ $(echo "$(bitcoind getbalance) > 0" | bc) -eq 1 ];then
      bitcoind sendtoaddress YOUR_NEW_ADDRESS $(bitcoind getbalance) "Comment for resender"
fi

It will check every minutes your bitcoind balance and resend each bitcoins to YOUR_NEW_ADDRESS.

Your probably need to check the fee.


The Bitcoin transaction fee depends on :

The size of the transaction
The current feerate

The transaction fee in $ depends in addition on the price of a bitcoin in dollar.
Simply put, the size of the transaction basically depends on the number of time you received bitcoins in the past (if you want to send 350$ the transaction size will be higher if you received a hundred times 3.5$ than if you received ten times 35$). This is the number of inputs of the transaction.
The feerate depends on the current demand for block space.

The bytes were 225

The estimated fee rate for your transaction to be included in one of the next ten blocks (1h40) is currently of 0.00002121btc / kilovbyte.
The current price of a bitcoin in dollars is about 8800$ / btc.
This transaction would cost you about 0.042$ (to be confirmed in the next ten blocks).
>>> 0.00002121 * 225 * 8800 / 1000
0.04199579999999999


Implementing an "ad-hoc-like network of payment channels" on top of Bitcoin network?

This is absolutely possible. The negotiation between the payment-channel participants can happen over the ad-hoc network.

However, each participant must still run a fully validating node at all times when he/she has an open channel-state, to be able to react to cheating counterparties. This validating full node may receive its updates over the ad-hoc network as well, but must be in consensus with the wider Bitcoin network.

If the ad-hoc network prevents Bitcoin nodes from connecting with other nodes outside of it, this will obviously be a problem.


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

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

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

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

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

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

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

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

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


Are bitcoin exchanges all connected to each others? or just close platform

Prices are determined by free market forces. The free market prices coins different on each exchange due to liquidity, fees, fiat conversion options, and terms. Prices follow similar patterns over time, but it is traders that determine what the price is.