How can I recover a blockchain.info wallet without the wallet identifier or the mnemonic?

Quick primer:

The identifier is a dash separated lowercase bit of text, like a32d0de4-818b-4aa3-...

It's specific to blockchain.info - other wallets use different systems. It was probably emailed to you.
The mnemonic is a 17 word bit of text, like skill course bleed oversize attempting lazer endure...
A bitcoin address looks like 175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W. A bitcoin address is not specific to blockchain.info. It's how you tell the faucet where to send the money. This is not what you use to log in.
All of this is different from your email address or password.

Troubleshooting steps:

You need to get either the mnemonic or the identifier. The identifier was probably emailed to you by blockchain.info, so check there. If you get the mnemonic, you can recover the identifier on the login screen with the 'Recover Wallet' button. I think it's also possible to get the identifier by contacting blockchain.info support, but you need additional information.

Once you have the identifier and the password, you can log in.

  Also, I read through a few not so similar Questions and answers where they spoke of downloading the wallet, which I know for sure we DID NOT do. Is this something you have to do?

It's something you need to do for some wallets. Not blockchain.info, though.


How do I get Avalon Miner Temperature from console?

I hate to necropost but I am in the middle of building a custom monitoring system for our company and had to deal with this exact problem. While I sadly can't release any code at the moment, there two values you are looking for: "Temp" and "TMax". "Temp" is the inlet temperature and "TMax" is the outlet temperature. At the moment my code just iterates through the JSON data looking for those strings with a regex and combines all the ones it finds into an overall controller average.


What exactly makes altering of data in non-bitcoin blocks hard?

The leading zeroes is what makes altering block data hard. One of the things that makes a block valid is that it's hash is less than some predetermined value. For simplicity, this can be thought of as the hash has to have some predetermined number of leading zeroes. However making such a block meet that requirements is hard and being able to do so proves that you have done some amount of work, hence Proof of Work.

Making a block whose hash has enough leading zeroes is hard because the output of SHA256 Double (the hash function used in Bitcoin) is random. Given some input, you can't predict the output of SHA256d without running the data through it. So the only way to get some block data (the input) to have a hash with some number of leading zeroes is to hash it, see if it meets the criteria, and if it does not, change it and try again. This is what miners do, and the criteria restricts the range of possible valid hashes to such a small percentage of the entire range of possible hashes that it takes the entire network 10 minutes on average to find a hash that meets the criteria.

Iif you wanted to alter the data in a block, you would have to recompute the Proof of Work, i.e. you would need to find a block with your altered data that has a hash with the required number of leading zeroes. Keep in mind that it took the entire Bitcoin network 10 minutes on average to find the block you are changing, so it will probably take you longer than 10 minutes to find a replacement. Then if you want to change a block that has blocks on top of it, you would need to re-mine those blocks too. Otherwise your fork of the blockchain won't be considered the best blockchain as it is not the longest.

While generating a hash is fast, having to do it 25 sextillion (2.5 * 10^22) times on average to find a block is a lot of hashes and is going to take you quite some time.


Found it: https://chainz.cryptoid.info/api.dws

You can see a list of all their supported block explorers through http://chainz.cryptoid.info/explorer/api.dws?q=summary


Have added my own implementation, complete with a fuzz tester to ensure that it works properly.  (The CodecMapping parameter is provided so that you can change the alphabet string as I've had to do from time to time)

#include <vector>
#include <random>
#include <string>
#include <algorithm>
#include <iomanip>
#include <iostream>

inline static constexpr const uint8_t Base58Map[] = {
  '1', '2', '3', '4', '5', '6', '7', '8',
  '9', 'A', 'B', 'C', 'D', 'E', 'F', 'G',
  'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q',
  'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y',
  'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
  'h', 'i', 'j', 'k', 'm', 'n', 'o', 'p',
  'q', 'r', 's', 't', 'u', 'v', 'w', 'x',
  'y', 'z' };
inline static constexpr const uint8_t AlphaMap[] = {
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xff, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xff, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0xff, 0x11, 0x12, 0x13, 0x14, 0x15, 0xff,
  0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff,
  0xff, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0xff, 0x2c, 0x2d, 0x2e,
  0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0xff, 0xff, 0xff, 0xff, 0xff };

using CodecMapping = struct _codecmapping
{
  _codecmapping(const uint8_t* amap, const uint8_t* bmap) : AlphaMapping(amap), BaseMapping(bmap) {}
  const uint8_t* AlphaMapping;
  const uint8_t* BaseMapping;
};

std::string Base58Encode(const std::vector<uint8_t>& data, CodecMapping mapping)
{
  std::vector<uint8_t> digits((data.size() * 138 / 100) + 1);
  size_t digitslen = 1;
  for (size_t i = 0; i < data.size(); i++)
  {
    uint32_t carry = static_cast<uint32_t>(data[i]);
    for (size_t j = 0; j < digitslen; j++)
    {
      carry = carry + static_cast<uint32_t>(digits[j] << 8);
      digits[j] = static_cast<uint8_t>(carry % 58);
      carry /= 58;
    }
    for (; carry; carry /= 58)
      digits[digitslen++] = static_cast<uint8_t>(carry % 58);
  }
  std::string result;
  for (size_t i = 0; i < (data.size() - 1) && !data[i]; i++)
    result.push_back(mapping.BaseMapping[0]);
  for (size_t i = 0; i < digitslen; i++)
    result.push_back(mapping.BaseMapping[digits[digitslen - 1 - i]]);
  return result;
}

std::vector<uint8_t> Base58Decode(const std::string& data, CodecMapping mapping)
{
  std::vector<uint8_t> result((data.size() * 138 / 100) + 1);
  size_t resultlen = 1;
  for (size_t i = 0; i < data.size(); i++)
  {
    uint32_t carry = static_cast<uint32_t>(mapping.AlphaMapping[data[i] & 0x7f]);
    for (size_t j = 0; j < resultlen; j++, carry >>= 8)
    {
      carry += static_cast<uint32_t>(result[j] * 58);
      result[j] = static_cast<uint8_t>(carry);
    }
    for (; carry; carry >>=8)
      result[resultlen++] = static_cast<uint8_t>(carry);
  }
  result.resize(resultlen);
  for (size_t i = 0; i < (data.size() - 1) && data[i] == mapping.BaseMapping[0]; i++)
    result.push_back(0);
  std::reverse(result.begin(), result.end());
  return result;
}

// Fuzz Testing the Encoder & Decoder
int main(int argc, char** argv)
{
  std::random_device device;
  std::mt19937 generator(device());
  std::uniform_int_distribution d1(1, 100);
  std::uniform_int_distribution d2(0, 255);
  CodecMapping mapping(AlphaMap, Base58Map);

  auto create_data = [&]() -> std::vector<uint8_t> {
    std::vector<uint8_t> data(d1(generator));
    std::cout << "Generating: " << std::dec << static_cast<int>(data.size()) << " points\nPoints:\n";
    for (uint8_t& v : data)
    {
      v = static_cast<uint8_t>(d2(generator));
      std::cout << std::uppercase << std::hex << std::setw(2) << std::setfill('0') << static_cast<int>(v);
    }
    std::cout << std::endl;
    return data;
  };

  std::vector<uint8_t> test_data, decoded_data;
  std::string encoded_data;
  size_t passed = 0;

  for (size_t i = 0; i < 1000; i++)    // Number of tests here!
  {
    test_data = create_data();
    encoded_data = Base58Encode(test_data, mapping);
    decoded_data = Base58Decode(encoded_data, mapping);

    std::cout << "Encoded\n" << encoded_data << "\nDecoded:\n";

    for (uint8_t d : decoded_data)
      std::cout << std::uppercase << std::hex << std::setw(2) << std::setfill('0') << static_cast<int>(d);

    std::cout << "\nTest Result: ";
    if (test_data.size() == decoded_data.size() && test_data == decoded_data)
    {
      std::cout << "PASSED\n";
      passed++;
    }
    else
    {
      std::cout << "FAILED\n";
      break;
    }
    std::cout << std::endl;
  }
  std::cout << "Passed Tests: " << std::dec << static_cast<int>(passed) << std::endl;
  return 0;
}


How good a "take off" on the block chain is Factom?

Factom provides a general purpose data layer secured by the Bitcoin blockchain.

Factom is a protocol run by a set of Federated Servers that allow users and applications to create their own "chains" of entries, which are really just whatever data the users and applications wish to track.

Factom then secures those chains by hashing them together with all the other data from other users, and a single hash is written to the Bitcoin Blockchain every 10 minutes.  Once data is entered into Factom, it cannot be changed, modified, reordered, or deleted.

One way to look at Factom is that it allows applications and users to create whatever data structures they need, then secure those structures with the blockchain.   So Factom provides a way to create audit trails that cannot be modified in any way.  Or ways of insuring entries in databases are both 1) secure, and 2) entered on a certain date.   Ways of creating audit trails for traditional banking that are as transparent and unalterable, and secure as the blockchain.

Because the history cannot be modified, Factom provides some interesting security features.  Identities can be verified and validated, and secured by time; nobody can insert a fake identity into the past.

The use cases are many, and go far beyond copyright.


Can someone explain how an HTLC is redeemed?

There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.

Redeemed using a valid pre-image by remote node:

The stack starts at <remotehtlcsig> <payment_preimage>
Since the HASH160 of <payment_preimage> is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now <remotehtlcsig> <payment_preimage> <remote_htlcpubkey>.
OP_SWAP is pushed to the stack, which swaps the top two items on the stack.
Stack is now <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
OP_SIZE 32 OP_EQUAL verifies that the payment_preimage is 32 bytes.
Since the payment_preimage is 32 bytes it will output 1. As a result OP_NOTIF will not be triggered, and hence OP_ELSE statement will be triggered.

OP_NOTIF is triggered is the value on the stack is 0
OP_ELSE is triggered if the preceding OP_IF, OP_NOTIF and OP_ELSE are not executed.

The stack is still <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
The OP_HASH160 will hash the paymentpreimage. Since payment hash is SHA256 of the payment preimage, we need to hash it with RIPEMD160 so that it is equal to HASH160 of the paymentpreimage.
If the hash matches, then the stack will be <remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG
If the signature matches the remote_htlcpubkey then 1 will be returned to the stack and this offered HTLC output is successfully spent by the remote node.

Redeemed after time-out by the local node:

To trigger the HTLC timeout condition, the local node will use the witness: 0 <remotehtlcsig> <localhtlcsig> 0
The stack starts at 0 <remotehtlcsig> <localhtlcsig> 0
Since the HASH160 of 0 is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> 0 <remote_htlcpubkey>
OP_SWAP swaps the top two items on the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
Since size of 0 is not 32 bytes it will return 0 on top of stack. This triggers the OP_NOTIF statement. Stack is still: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
OP_DROP drops the top item on the stack which is 0. Stack is now : 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey>
2 is pushed to the stack. Stack is 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 2
OP_SWAP swaps the top two items on the stac. Stack is: 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey>
<local_htlcpubkey> 2 OP_CHECKMULTISIG is pushed to the stack. The stack is thus 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey> <local_htlcpubkey> 2 OP_CHECKMULTISIG.
The above is a multisig output which can be spent only with valid signatures from the local and remote keys. These keys are exchanged when adding the HTLC. The output of the above transaction is sent to the local node using a to_self_delay using the time-out transactions.


Is there a good website or resource comparing how all exchanges are structured under the hood?

I can't say I've seen one. These links list resources and exchanges:
https://bitcoin.org/en/resources
https://bitcoin.org/en/exchanges
It might be worth looking at crypto venture capital companies to see if they have any market overviews.


if nobody is mining then there will not be bitcoins generating anymore and verifying bitcoins ?

Correct. Mining activity has several goals including:

Generating new bitcoins (until 21 million bitcoins).
Verifying new transactions and persisting them in the Bitcoin system (in Bitcoin block-chain).

Mining is crucial for the Bitcoin system and therefore the Bitcoin system provides the incentive (Bitcoin reward) for everybody that participates in mining. The security of Bitcoin is directly dependent to the computing power of network's miners.

One question that may exist in this context is "Why may miners stop mining?". Miners may stop mining because of a decrease in Bitcoin value. The miners' reward is a constant count of bitcoins (currently 25 bitcoins, which is halved every 4 years). If the value of Bitcoin decreases, the reward for the miners will decrease equivalently, too.

The worry would be that Bitcoin gets caught in a "Death spiral".

  This leads to the possibility of a death spiral in which loss of
  confidence in Bitcoin could cause the Bitcoin price to go down, a
  falling price lowers the incentive to mine and the equilibrium mining
  rate, lower mining rate leads to the currency being easier to subvert,
  and this leads to a further loss of confidence in the currency.


Why Bitcoin address are 25-34 bytes long when RIPEMD 160 & SHA-256 are only 20 bytes and 32 bytes long respectively?

Bitcoin address is generated as follows :

First 256 bits of Private key(k) is generated using underlying operating system's pseudo random number generating function (in wallet).

Then Public key (K) = G * k. , where G is constant on the elliptic curve. i.e. equivalent to k times addition of G and the resulting point K is on the curve which is 65 Bytes.

The address is calculated by performing SHA256 followed by RIPEMD160 on public key (K). so that would be of 160 bits = 20 Bytes of address.

Now, Add version prefix 00(in hex). Perform SHA256 twice on it. Take first 4 Bytes of result and append it to (prefix || address).

Resultant would be final address.


Is UTXO synonymous with leftover money in an address?

Is UTXO synonymous with leftover money in an address and the only reason UTXO is even a concept is due to security concerns of not changing an address after every transaction? Hence, your "unspent outputs" must be moved to x address.

Not really. A UTXO is more like a particular bill or coin in that it's a specific "chunk" of value.

The reason UTXO is a concept is because bitcoin is designed as a set of UTXOs rather than as a balance. It's the same way cash is designed as a set of bills and coins rather than a balance. When you say, "I have $100.43 in cash", you mean that you have some set of bills and coins whose value totals to that amount. This is analogous to a set of UTXOs in bitcoin.

  Or am I missing something completely?

I think what you're missing is that bitcoin was not designed to have accounts with balances as the primary implementation but to instead have a set of unspent outputs.

  I read that you might have $10 balance in an address but your UTXOs might be $2 and $8 in the same address. How does this affect execution of a transaction on the blockchain?

The blockchain doesn't care about addresses. If you have two UTXOs that you have the correct key(s) to claim, you can form a transaction that claims those two UTXOs and creates some new UTXOs as its output.

  Can somebody please shed some light on the difference between UTXOs and current address balance?

A "current address balance" is the total value of all the UTXOs a particular key can claim.


How to check if the segwit2x fork was adopted?

Here's an official announcement of the fork having taken place. According to the official website the fork is planned for block 501451 which has indeed occurred about 8 hours ago.

The stats of their mining pool don't look to promising though, but it might be too early to tell. Also keep an eye out on their subreddit and other social media.


It is not a superficial gate-keeping password. The password on your wallet is an encryption passphrase.
Related answer with more details: https://bitcoin.stackexchange.com/a/89278/26873


What if two people want to spend same input at the same time

Eventually all messages are put in a sequence. The key word is "eventually".

Let's say there are two users A and B trying to spend a transaction at the same time.

A's transaction reaches Node1 and B's transaction reaches Node2.

Both nodes include the two different transactions in a block and are able to mine the block using those transactions.

Further, when Node1 receives B's transaction it is rejected as a double spend and when Node2 received A's transaction, it is rejected as a double spend as well.

At this point Node1 and Node2 are working on different chains. This needs to be resolved, and the following explains how.

Now, when Node1 and Node2 broadcast their mined blocks to the network, there will be two competing chains. Depending on the which chain other nodes are using you will get 1 confirmation for the transaction from different nodes. That is why spending transactions with 1 confirmation is not too clever an idea.

Eventually, both nodes will reorganise as more blocks are mined top either Node1 or Node2's block. The issue will be resolved when one chain outputs 2 or more blocks more than the other. The losing chain will be discarded by all nodes (who must accept the longest chain as the most valid). At that point the double-spent transaction that did not make it into the valid chain will be invalid forever.

Hope this helps.


Is it possible to determine Bitcoin ownership distribution?

No, it's not definitively possible to determine ownership of bitcoins.

It may be possible to identify miner reward addresses that are inactively used, but accumulated regularly at one point. Search for addresses with a large balance, the outputs of which have never been spent or have a large amount of unspent outputs.

It may be possible to find patterns in early mining, up until pooled mining came into existence. Search for blocks relayed by the same IP address, but at irregular intervals. This may indicate solo miners who "tried it out" but lost their keys or are in fact sitting on their wallets. This may only be possible through Blockchain.info's records, because the relay address is not preserved in the blockchain.


Are there any other blockchains that can spawn child-chains within their own blockchain like NXT's Ardor platform?

With special transactions, Bitcoin has the capability of supporting sidechains. This is different from childchains in that the sidechain itself is a different blockchain and is not extended from the main blockchain. The paper describing sidechains can be found here: https://blockstream.com/technology/sidechains.pdf and an implementation of those sidechains can be found here: https://github.com/ElementsProject/elements.


How to get private key from litecoin-qt wallet?

Go in the console and type : dumpprivkey litecoinaddress

Use the help if nessassary.

The console is in : Help\Debug Windows


Bitcoin-Core does serval read and write operations. Blocks can also get deleted in case you have enabled -prune. There are many read operations because your node will very likely serve/relay blocks to other nodes.

The performance of bitcoin-core is more likely constraint by your CPU because of heavy EC verify operations.


Possible To --enable-wallet After Syncronization With Blockahin?

What I am now wondering however, is if I sync the entire blockchain (300GB+) and at some point want to --enable-wallet, will I be able to do so without any incompatibility issues?

Yes, there's no issue with this. You will need to rebuild with --enable-wallet (or use the release binaries which bundle BDB), but this will have no impact at all on the synchronization state. You can switch between having the wallet compiled in, and back with no concerns.

Furthermore, how can I update to the correct version of Berkley DB (4.8+) so that I can --enable-wallet. I already ran the script $home/bitcoin/contrib/install_db4.sh which did not alleviate the error when running ./configure to test the system for compatibility. I still get the error that the current version is incompatible.

Depending on your distribution, you almost certainly have a version which is too new (5+), and many distros don't bundle old versions of it anymore. Bitcoin Core uses a very old version for compatibility, as newer versions would produce a wallet that can no longer be opened in older versions. Eventually this will be removed as a dependency except for some importing tool, but for the moment we just have to deal with it, or use the static release binaries which are reproducably built.


Segwit: Arbitrary data storage in witness?

Your transaction, although not invalid, is non-standard. Since it is non-standard, it will not be propagated and will be rejected for being non-standard. However this does not mean that it cannot be included in a block; it can. It only requires that the miner and all of the nodes between you and that miner must be running some software that accepts and relays non-standard transactions. However not many nodes actually do, so you may have a hard time getting good propagation of your transaction.


how to capture only one part of the getrawtransaction

Looks like you're indexing the array incorrectly.

Try:

print_r($txidarray[vout][1][scriptPubKey][addresses][0]);


What will happen when all 21M bitcoins are mined?

the only option available will be to increase transaction fees?

You are right, when no more bitcoins can be mined, the only reward for miners are transaction fees.

According to Section 6 of Satoshi Nakamoto's Bitcoin whitepaper, 2008 - the only mining incentives are these two possibilities.

  If I have to pay anyway fee, I can pay that to centralized entity now also.

Of course, Nakamoto intended to create "an electronic payment system" but Bitcoin appears to be mostly used as a speculative investment platform.

It may be that this predominant use has hastened the increase in mining difficulty and made use of bitcoin for small retail transactions unattractive to many in a shorter timescale than Nakamoto may have envisaged.

According to Bloomberg July 2017:

  Bitcoin Acceptance Among Retailers Is Low and Getting Lower

There have been a variety of efforts to make Bitcoin more scalable and more usable as an electronic payment system - especially for smaller transactions. One of the more prominent is the Lightning Network - but this seems to be an additional layer with some overtones of corporate financial institutional structures.

According to the Lightning Network whitepaper, January 2016:

  The Bitcoin blockchain holds great promise for distributed ledgers,  but
  the  blockchain  as  a  payment  platform,  by  itself,  cannot  cover  the  world’s commerce anytime in the near future.

When you create a Bitcoin transaction today, you are essentially placing trust in two or three large Chinese corporations who process the majority of transactions and who are somewhat beyond the reach of your government (unless you are a PRC citizen) and it's financial regulators.

It is yet to be seen whether LN will be as decentralised as its proponents hope or will, as some detractors say, also come under the control of large corporations.


Are transactions many-to-many? If so, who decides on the grouping?

Transactions are not grouped or collected together in any fashion, unless the sender of every Bitcoin within that transaction agrees to that. CoinJoin is one way of grouping your transaction together with other people.

There is also a proposal called 'MimbleWimble,' which would make it possible to combine many transactions. This has not been implemented, though.


How do I generate coins on testnet? CPU, GPU, FPGA? Are there pools?

Testnet is designed to test Bitcoin software - including parts that have to do with finding blocks. As such, it should be easy for developers to generate testnet coins.

Because of this, it will be easy to solo mine on a CPU to generate them, and you should not use anything heavier than that because you would ruin it for everyone else.

It is also not designed to test pools, by the way. If you need a pool for whatever you're doing you can do that (but don't bring too much hashpower to it), but if it's the pool itself you're testing, do it on the main net.


transfer of bitcoin from bitcoin cash wrongly.

As far as I know that any transactions that are in the blockchain cannot be undone so if it has confirmations then you lost the coins


Does Bitcoin prefer broadcasting transactions crediting it?

According to the Satoshi client transaction exchange behavior, this does not seem to be the case. However, that page isn't written well.  Looking at the actual source code, I cannot see any special behavior for transactions to an address in your wallet, but I do see special behavior for transactions from such an address.

Thus, I do not think the behavior you observed is actually valid, and is more likely a pattern you noticed because human beings are too good at noticing patterns for our own good.


It's the same: the proof-of-work is that the scrypt hash of the block header must start with a certain number of zeros (or, more precisely, be numerically less than a certain target value).  However, the scrypt hash is not what's used as the block ID; rather, the sha256d hash (double sha256) is used instead.  The sha256d hash doesn't have to follow any particular pattern.

For instance, the previous block field of a header contains the sha256d hash of the previous block's header, not its scrypt hash.    The scrypt hash of the header isn't contained anywhere in the block chain, and the block explorers I checked don't seem to show it, though it would be nice if they did.

I don't know exactly why this choice was made.  It could be for efficiency: there might be places in the code where we need to find the ID from the block header, but don't need to verify the proof-of-work.  Since sha256d is much faster than scrypt, it would save time to be able to use sha256d in such cases.  Or it might have been for convenience, so that there was less code to change from the original Bitcoin source.


Any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key. Assuming your random number is in that range (and it's extremely likely that is the case), it should be just as fine of a private key as any other number.  In fact, you shouldn't even bother with checking if the address is already known because:

Probability tells us it isn't used
Its existence on a chain explorer is not proof that nobody else has generated that key
By checking, you may be telegraphing that you own that key

Be more concerned about how your key is generated, rather than is a particular number is vulnerable to some unknown attack.  Make sure your dice rolls are done in such a way that every byte is just as likely as every other byte.  I've used a D8 in conjunction with a coin flip in order to generate 4 bits at a time.  If the coin is heads, I use the D8 at face value.  If tails, I add 8.  I count 16 (tails + 8) as 0.  If you work it out, you'll see that this generates a perfectly random number between 0 and 15, or one hexit.  Do this 64 times, and you have a 256-bit key.


Is it possible to buy or send bitcoins without an intermediary?

Do not mix the fees, and its base. Whenever you transfer amounts of value between two fiat currencies (let's say GBP to Euro), you pay a fee. So if you go from GBP to Bitcoin or from Euro to Bitcoin, you pay a similiar fee to those, who are "in fiat currency" to ramp up.

Now, when you are within the bitcoin ecosystem, and you transfer bitcoins from your account to my account, then you pay a miner fee. Miners make sure, the bitcoin network is working correctly, and this is to be paid.
When you say the whole idea was to get rid of third parties, than you omit the miners. I guess you mean with third parties the "old structures" of the fiat world... They are indeed not required, once you are in bitcoin world.

  connect to the public ledger somehow and acquire bitcoins without a
  third-party?

yes, you can setup your own mining equipment, mine some blocks, and get rewarded for it. Otherwise, if you convert Euro/GBP/Dollars, no (see above).

  Can programmers somehow connect to the public ledger and do
  transactions without bitcoin wallets or fees?

Yes, with a mining node. No in general. Example: I have my own set of script to transfer bitcoins between wallets. In this sense I can be considered a programmer :-) I assemble a tx, and send it into the network (aka "connect to the public ledger", following specific rules). For the miners to bring my tx into a block, I have to pay a fee.

So there is no such thing as free beers :-)

I consider reading the book "Mastering Bitcoin" from Andreas (http://chimera.labs.oreilly.com/books/1234000001802/index.html) for further info.


Bitcoin mining is principally an integer maths task, not a graphics task.  It just so happens that the hundreds of processors found on modern graphics cards can sometimes be suitable for parallel calculation of the bitcoin task, at upwards of a hundred times the best available rate from four cpu calculations.

See wiki reports on bitcoin hardware for comparison figures.

Unfortunately for you, Intel copied some parts of modern GPU designs into their system on a chip, but to save money they left out some transistors here and there which might not get used in direct X 11 graphics but would be necessary for parallel calculations for bitcoin.

So, you have on-chip graphics suitable for screen display and a few other specifically graphics tasks, but you do not have a general purpose massively parallel GPU for bitcoin calculations.

The error message "clDevicesNum returned error, no GPUs usable" appears on one of my systems which does have a suitable graphics card for bitcoin mining and does find openCL drivers for it when configured before compile.  I'm trying to find out what is incorrect in my configuration.


I used WarpWallet. I booted my computer into Linux, copied WarpWallet off my flash drive, ran it, put in my passcode (39 random hex digits that I've memorized), and I had my address. (I triple checked that the same passphrase always gave me the same private key, and all this time the computer was, of course, disconnected from the internet) I wrote down the public key on a piece of paper, then transferred all my old cold-storage bitcoin to it. https://blockchain.info/tx/13fd0f4ef557317871965f12d02e17069dc782d3dce9f2f44c4b751c3c856595


At which point and how does the miner who successfully solved hash get coins?

The block subsidy isn't awarded by anyone. It is taken by the miner, by virtue of creating a block that gives himself money.

The system's role in this is restricted to permitting blocks to indeed contain such an (otherwise unbalanced) payment.

If you have a fork with two branches, then within each branch there will be a payment to some miner. Which one is eventually treated as valuable by the world depends on which of the two gets built on. As far as the system is concerned, there are two possible versions of history, and both are valid. In one of them A gets paid, in the other one B gets paid. At some point, one of the two chains gets longer, and everyone switches to accepting that one.

In order to avoid random forks for flipflopping people's balancea (if they got paid by a block subsidy), bitcoin transaction outputs from coinbase (the type of transaction that credits the subsidy and fees to the mimer), they must be buried by 100 additional blocks before being spent. That is a special rule, called the maturity rule, which only applies to coinbase transactions.


How do you import Block Chain from bitcoincharts?

If you are using the not-yet-released Bitcoin.org client v0.7, you can use the -loadblock=FILE to import the blockchain from the blk0001.dat file. [Update: actually need to do two of those inline, -loadblock=blk0001.dat -loadblock=blk0002.dat in order to get both to load.]

There is a blockchain with index through block 170,000 here:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

That is the most complete distribution of the blockchain that I know of where the blkindex.dat is included.


Do Full Nodes perform Proof of Work to validate a Block?

Hashcash-style proof of work is a simple search process: Try lots of nonce values until you get an acceptable solution.  To verify a node simply just has to try one value, the one the miner provided.  So it uses the same test but does not search, as a result it does very little work.

The Bitcoin software hasn't really validated transactions twice since 2012. Caching is used to reuse the validation effort from the first time the transaction was seen, especially for the digital signature verification.

Very careful engineering has been required to make sure that the handling of unconfirmed transactions can't accidentally cause invalid blocks to pass. This is especially a concern because complications like locktimes and soft-forks can make the validity of a transaction some what conditional. But in the latest software really the only validation needed at block time of an already seen transaction is the locktimes and double spending checks.


Sending lightning payment between TOR lighning nodes, any specific setup required?

Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?

No, that's very unlikely. (and contradictory)
Are the channels you created announced ?
Are your two nodes connected to the network ? For a node to find a route it needs to be connected to the peer-to-peer network to trade gossip and build its view of the current state of the network (opened channels and whether they are active).
Without this information there is nothing for it to search routes in.
You can verify that your channels are announced with listpeers (the channels array), or by running listchannels <scid> on your first node (with scid the short channel id of a channel of your second node).
If listchannels returns an empty array you need to connect to some public nodes and wait for your node to sync gossip with the rest of the network.
Finally, as it'll surely be your next concern: be sure to have incoming capacity in at least one of your second node's channel :-).


Storing an encrypted private key on a server

I am planning on building a small e-wallet website to learn the basics of encryption and handling accounts, transactions, and balances in Bitcoin.

This is really not the place to learn. Even the most hardened Bitcoin services get attacked on a regular basis.

  Using brainwallet, the process for account creation is this:

"Brain wallets" are an incredibly easy way for users to lose all of their funds. It happens every day. Think your 8 word sentence is strong enough? Chances are that it's not, and there's at least three bots that will empty the wallet in seconds of it receiving funds.

  Now, whenever a user wishes to spend a transaction on my site I am attempting to use brainwallet to send transactions.

The code you're referencing is just a frontend for blockchain.info and the bitcoinjs library.

  As a side note: is this a sound process for storing and transmitting data to the server?

Blockchain.info uses this method for it's web wallet, but no, it's very unsafe and offers very little in the way of security. If your server is compromised, the keys still are. If you are malicious, you can just backdoor the client scripting and nobody would ever know. It is not secure, and a service using this type of system shouldn't be advertising itself as such.


Bitcore-wallet-client "Server response could not be verified"

The problem was that I was creating the transaction proposal and publishing it, after that I used the result from createTxProposal and passed it to signTxProposal.

turns out that the txProposal returned from createTxProposal doesn't have the property proposalSignature (which is filled when the transaction is published).

so, to solve this I had to get the transaction proposals (after publishing) and send the transaction fetched as argument to signTxProposal.


BitFinex API call returns 400 bad request

Finally discovered the fix: hexhash has to be lower case:

string hexHash = BitConverter.ToString(hash).Replace("-", "").ToLower();


When you look at blockchain you will see that your transaction contains 0.0001 BTC which is not zero fee, so it is very likely that your transaction will be confirmed.

You have various options if the transaction doesn't get confirmation:

Reset your blockchain and wait until it's up to date again (keep your device on power and connected to internet). After the rescan, stuck transactions should be gone and your BTC free to spend again.

OR

Relay stuck transactions to a miner that accepts non-standard fees. You can use the trusted peer option for this, just remember to clear that option after your problem is resolved. Also see https://en.bitcoin.it/wiki/Free_transaction_relay_policy.

From: UnstickLowFeeTransactions

Note: There is certain time after blockchain.info clears the transaction if it isn't taken by any miner +- 72 hours. I would recommend you wait this time.

OR

Download electrum or any bitcoin client
Dump your private keys from blockchain.inf and import them. Use Pywallet to delete that transaction from your wallet.
Create whole new bitcoin wallet at blockchain.info and sent entire transacion again. (Wallet mustn't be created under same account).
send your transaction again.

Conditions for confirmation of zero transactions:

Transaction is smaller than 10 thousand bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)

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

Source of my post:

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

https://bitcoinarmory.com/download/troubleshooting/


Could Taproot or Graftroot enable the execution of complex scripts?

First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?

The taproot email doesn't specify how the script is placed into the merkle tree.  It can be that each leaf node in the tree is a different script (BIP114-style) or it can be that a parameter can be passed that allows extracting multiple leaves so that parts of the script can be reused (BIP116-style).

The reason this detail is not in the taproot email is because that email was about rearranging the previous ideas about merklized scripts (MAST) so that the expected default condition (everybody signs) was the easiest and cheapest option to use with no need to actually handle the merkle tree in the expected case.  The ideas about how to organize and use the tree are a separate discussion.

  Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.

The merkle root / public key for taproot consumes a fixed number of bytes (say 64), which is trivial, but the spending transaction will have to provide the spending script as well as a merkle proof providing a list of hashes (and a few bits of path information) proving that the provided script connects to the taproot's merkle root.

This information will be subject to the fundamental block size limit of 4 million weight units and, depending on how it is implemented, may also be subject to Bitcoin's current limits on witness size (10,000 weight units for segwit v0).  The good news is that it's impossible for an honest person to create a merkle tree that requires more than about 8,000 bytes to create the merkle proof (not counting the script) even if they had at their disposal all the energy in the universe.  (Assuming we use Bitcoin's SHA256d hash function.)

The above is an illustration from my article about MAST showing how the encoding of alternative scripts (subscripts) into a MAST grows at log2 whereas it grows linearly with the existing mechanism.

For a script with a million possible outcomes (tree depth equals 20) would require about 643 bytes (20 * 32 + ceil(20 / 8)), allowing actual witness script and witness data to be up to about 9,300 bytes.  Of course, if everyone signs, you don't need to provide any of that data---you just push a single signature.


Confused on using SHA256 code from Bitcoin Core

sha256.h has the exported (visible from outside) methods and functions. To compute SHA256, you should #include that.

sha256_sse4.cpp
sha256_sse41.cpp
sha256_avx2.cpp
sha256_shani.cpp

contain SHA256 transform functions (used in SHA256.Write), each specialized for different processors with different instruction sets. Above is the list in order, most of the computers support SSE4, but only a few support SHA-NI instruction set, which is the fastest way a new processor can calculate SHA256.

sha256.cpp contains other methods that aren't a bottleneck, functions that check which instruction sets are supported, tests, as well as a pure-C++ transform function for older and non-x86 computers.

hash.h favors polymorphism via C++ templates.

Examples:

hash std::vector<something> vch to std::vector<something> vchHash
hash std::vector<something> in to std::vector<something> WitnessV0ScriptHash
hash uint8_t * nonce.begin(), uint8_t *  hash.begin(), unsigned char pubkey[], std::vector<unsigned char> vchSig to std::vector<unsigned char> entry
hash op_true to witness_program


Explicit message length in Bitcoin Signed message

It's a quirk of the original implementation of the message signing logic which was introduced in Bitcoin Core in 2011.

When the message is signed, it must be serialized before it is hashed. The serialize methods in Bitcoin Core are shared between the network, hash preimage, file, etc. serializations, most of which require that the data be prepended with a compact size uint that specifies the length of the data. Thus those methods will prepend such a compact size uint when serializing whatever data.

The implementation of the message signing logic used those same serialization methods in order to produce the preimage that would be hashed. Thus the strings must be prepended with their lengths for the hash preimage.


sum(VOUT) > sum(VIN) -- Is this a possible scenario?

Such transactions would be invalid. While you could create them, all nodes would reject them as invalid and such transactions would never confirm. If this were possible, then it would be possible to create money out of nothing (except in Coinbase transactions) and that should be impossible.

You have either constructed your transaction incorrectly, or are interpreting it incorrectly.


How get address from ScriptSig: PUSHDATA(N)?

In general, you can't.

You need to look at the scriptPubKey of the output that is being spent.


See https://en.bitcoin.it/wiki/Data_directory

Copy over your %APPDATA%\Bitcoin directory to ~/Library/Application Support/Bitcoin/

Your AppData directory should be:

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

If not, you can always run explorer %APPDATA%\Bitcoin in Command Prompt (Super-R, type cmd, hit "Run") to find it.


how to enable wallet in a confirmed node

Yes, that is a wallet feature. You would have to recompile without the --disable-wallet flag, starting back at executing the autotools configure script: ./configure. See https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#disable-wallet-mode.

You also have to make sure you don't set the -disablewallet flag when you run bitcoind or have it in your bitcoin.conf file.

If you need to recompile, you could still back up the data in the .bitcoin folder, which includes the blockchain and UTXO set and copy it back over when the installation is complete. That way you don't have to download the blockchain again.


What disadvantages are there when broadcasting a transaction via a 3rd party application?

The main disadvantages, are you are trusting the third party to actually relay the transaction, that third party can now link you to the bitcoin being moved in your transaction, and you are trusting other people running full nodes to verify your transaction. Your most secure and privacy-centric option would be to use a wallet which relays your transactions through a full node you run yourself. This way you are not trusting a third party to relay your transaction, and running a full node will help verify your own transaction. Some examples of wallets which do this are the wallet built into bitcoin core, Armory, and Electrum allows you to run your own Electrum server, CoPay allows you to run your own server as well, but last time I looked into this it was not a simple process. The drawback to this, is you will need to store the blockchain on your computer, which can require a lot of storage space.

EDIT: The bitcoin wallet mSIGNA, also allows you to use your own full node.


What does it mean by Public Key on the Vanitygen Pool?

ThePiachu explains it like this:

  The idea is, that you can generate a vanity address without even
  knowing what private key it will actually belong to. One party grabs a
  random ECDSA keypair and saves the private key for themselves. They
  later can issue a request for a vanity address to be created, by
  supplying the public key form that keypair, their desired pattern and
  so forth. A person takes with looking for the vanity address is
  required to brute force random ECDSA private keys, get their
  corresponding public keys, add them to the provided public key, and
  proceed normally with SHA, RIPEMD and base58 until they receive the
  desired pattern. Then they give the private key they found to the
  first person, which adds the two private keys in order to get their
  vanity address. The best thing about it - the person looking for the
  solution won't know what the resulting private key is! This means that
  you can outsource your vanity key generation without needing to trust
  any third party.

  An example (available from gobittest website): We have a private key:
  18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725 which
  maps to public key:
  0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A
  299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

  and say we want to find a pattern "166". One of the solutions takes a
  form of a private key
  B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
  mapping to public key:
  049C95E0949E397FACCECF0FE8EAD247E6FD082717E4A4A876049FB34A9ADED110DFEA2EF691CC4
  A1410498F4C312F3A94318CD5B6F0E8E92051064876751C8404

  If we add the two public keys (like the person looking for the
  solution would do), we get a public key:
  0436970CE32E14DC06AC50217CDCF53E628B32810707080D6848D9C8D4BE9FE461E100E705CCA98
  54436A1283210CCEFBB6B16CB9A86B009488922A8F302A27487 which is
  equivalent to this address: 166ev9JXn2rFqiPSQAwM7qJYpNL1JrNf3h

  If we add the two private keys (like the person requesting the address
  would), we get:
  CA65722CD418ED28EC369E36CFE3B7F3CC1CD035BFBF6469CE759FCA30AD6D54 which
  maps to the same public key as the sum of the public keys, and thus -
  to the same address.

  Since this is a model that requires basically no trust from any party,
  I've decided to create this "Vanity Pool" to enable people to easily
  outsource their vanity address creation, as well as enable people
  wanting to earn some Bitcoins to use their machines for something
  different from traditional mining.

The simplest option to get the keypair to get started with the vanitypool is to go to https://www.bitaddress.org/ and generate a new address. Note down the private key. Now switch the tab to "Wallet Details" and enter the private key. One of the resulting fields is the "Public Key (130 characters [0-9A-F])" which has exactly the required format that is needed for the vanity pool.

Once a solution is found just combine the result that is mailed to you with the private key you noted before and you can import it into your Bitcoin client.


How can I run bitcoind on test and production networks, at the same time, on the same computer?

You can run a mainnet and testnet bitcoind next to eachother without problems. They do not share the same database (one will use the testnet3/ subdirectory).

What will conflict is the RPC port, as they will both try to bind to port 8332 for receiving RPC connections. Use -rpcport=N on one of them to use a different port.


Are wallet address generators considered a dapp? like bitaddress or warp wallet?

I think this comes down more to semantics than anything else (and thus might make the question off-topic as opinion based), but I'll give it a shot.

I would classify BitAddress or WarpWallet as standalone programs (or even scripts, although I would lean towards program since they are interactive), much in the same class as a calculator app. Yes, they don't rely on a centralized server (barring distribution, which could also be done over torrents or something). They don't work in the same way as you would expect a dApp to. There is no data replication/distribution to peers. There is no interaction with a larger network at play here. They work fine in isolation and have no need to access any external resources.


Is it possible to spend partial amounts from a paper wallet?

The key to understanding what's going on here is to realize that there are not two, but three components of a bitcoin transaction that determine where coins end up. These are the inputs, the outputs, and the oft forgotten remainder. The inputs to a transaction are the addresses that have coins that are to be spent, and the outputs are the addresses where the coins are to be sent to. The reminder is the amount of coins left over when the inputs are greater than the outputs. In a bitcoin transaction, the remainder goes to the miner that confirms the block containing the transaction. That's why there needs to be a "change" address. If you have more coins in your input addresses than you want to send to the outputs, you need to send some back to yourself otherwise you'll loose them.

The standard bitcoin client handles this transparently by generating new change addresses when you complete a transaction. This is the "safe" thing to do because technically re-using an address can open you up to a kind of attack that would allow whatever coins remain to be stolen. This attack relies on being able to calculate a private key from a public key, however, so until quantum computers become a thing you don't really need to worry about it.

Though it is "less" safe, it is valid to use an input address also as an output address. I believe this is what blockchain does with a watch only address. Instead of creating a change address for the remainder in a transaction, it sends the change back to the original address. This means that you can use a watch only address multiple times without creating a new paper wallet. This means that you have to use blockchain when you are spending coins though. If you import your keys into bitcoin-qt and spend the coins, your paper wallet will no longer contain any coins. They will have been moved to a new change address.

EDIT:

I wanted to check and see if this is how blockchain actually works, and my guess is correct. If you spend coins from a cold storage address, blockchain will send the change back to the original address. You can see an example of this sort of transaction here.


Derive new public keys from a public key?

Is there a kind of homomorphism between the set of private keys and public keys?

Yes. You can think of f: G -> H being the function that derives a public key (i.e. something from the set of H) from a private key (something from the set of G).

More to the point, f(a + b modulo n) = f(a) # f(b)

(I'm using the # symbol above to mean 'secp256k1 elliptic curve point addition')

  Because the article says that you can either sum before or after the public key is generated.

That's accurate.


Pushing tx to the network via AJAX, without installing bitcoin

Looks like the premise of this question was wrong. Blockchain.info DOES support raw transactions via ajax however you have to include ?cors=true to the end.

Note they also require application/x-www-form-urlencoded data. Here's what my request looked like in angular

$http({
    method: 'POST'
    ,url: 'https://blockchain.info/pushtx?cors=true'
    ,data: $.param({tx:txHex})
    ,headers:{
        "Content-Type":"application/x-www-form-urlencoded"
    }
})


Bitcoins missing following wrong bank account number entered

I believe you are undoubtedly the victim of a scam.

It is extremely unlikely you will be able to trace the money to any identifiable individual. Bitcoin is designed to make this very difficult.

I suggest you firstly report to police that you are the victim of a fraud, secondly accept that the money is irretrievably lost and move on with your life.

You will receive private messages from people telling you that they, or someone they know, can recover your money. They also are fraudsters. I strongly suggest you ignore them. You will be tempted greatly but it can only lead to further loss.

Some reasons why this is the case:

  I commenced trading with an online Bitcoin trader called Assetgates, who had contacted me via my mobile phone.

Unsolicited contact by people using disposable phones (or by throwaway account on Facebook) claiming to be a broker/trader/miner or other expert is a sign of fraud.

  My broker then informed me that my money was with the Miners

This is not the way Bitcoin works. Miners do not hold investor's money.

  the Miners who would give it back if i forwarded 17%

This is not the way Bitcoin works. Miners cannot reverse transactions.

Anyone who had previously received your "investment" money could create a new Bitcoin transaction to return it to you for a cost of a few pennies. If they were greedy enough to want to keep 17% of your money they could simply send you the other 83% directly without needing any up-front fee from you. The up-front fee is another clear sign of dishonesty.

  the miners would divide the money between themselves

This is not the way Bitcoin works.  Miners cannot take control of money that is under the control of other people.


What GUI clients support multisig transactions?

Armory is a client for advanced users that has support for multisignature
https://bitcoinarmory.com/


Detect received transactions of thousands of Bitcoin addresses

This doesn't sound correct to me.

You're relying on a centralized service to fetch blocks.  What if their system has an error and sends you incorrect data?
What if their service is unreachable?
It doesn't seem like you have any way to handle blockchain reorganization.  You might end up crediting a payment twice, or crediting where a double spend was successful in a competing chain.

Consider looking into something like BTCpay which FOSS self-hosted bitcoin payment processor.


could'nt run wallettemplate project in bitcoinJ

Bytecode version 55 is Java 11. The JavaFX from openjfx that you are using was compiled with Java 11, but you are compiling with Java 8. Java 8 already includes JavaFX, so you don't have to add it via maven from openjfx. So you can either upgrade to OpenJDK Java 11, or remove the openjfx dependency from your project.


How to calculate the risk-free rate of cryptocurrencies?

Bitcoin itself has no returns: 1 Bitcoin is worth 1 Bitcoin, always.  Presumably you actually want to discuss the returns of a Bitcoin plus ordinary currency pair, such as BTC/USD.  In that case you'd would treat it the same as you would treat any other asset trading against USD and use some presumed near zero risk bond rate, like US treasuries, in your analysis.


How can one find how much "room for arbitrage" is there in the Bitcoin market?

I am not an expert on this, but I will answer from my personal experience from the past couple of months. Here are some things I noticed:

MtGox rules the market. The price there leads and the other exchanges follow. Sometimes TradeHill moves a few decimal points on its own above or below MtGox, but it usually goes back to where it was after a few hours.
The price difference between exchanges with APIs rarely goes above $0.3 (the most common opportunities are around $0.1/BTC). So with the current fees you will earn very little from each trade - note that on smaller exchanges, it is very easy to move prices up and down so you are doing arbitrage with very small trades.
You must be fast. There are already people doing this and the opportunities don't stay up for long. If you are not careful your orders will end up pending.
Exchanges without APIs have much more arbitrage opportunities. Bitmarket for example is some times $1 or more off the current MtGox price. Of couse it is also much more time consuming to arbitrage manually.
There are days when nothing happens and others when a lot happens. You have to be ready and keep a lot of money on each exchange if you want to catch it all. There are huge volume differences so you should split your money accordingly.

I am still testing things out, but I don't think that you can make a lot of money out of this. It may be interesting to use it as a complement to other automated trading strategies though.

Just another note:

Moving money/bitcoins around to grab opportunities in exchanges with APIs won't work because of fees (even if small) plus waiting time. You usually have a few minutes to grab opportunities. If you are lucky you can sometimes find an opportunity that lasts a couple of hours, but that happens like once a week.

All of this is from personal observations during July/August 2011. Things will of course change and the market will probably become more and more efficient.


According to the website, if you click on "Auto Withdraw Enabled", you see:

"Payments are automatically sent every Monday to all accounts with a balance greater than 0.00005460 BTC".

For example, yesterday I received my most recent payment around 1 AM on Tuesday EST.  They send the BTC with a note saying:

They state that it can take a while to get the payment approved.  From my experience with the site, I find they are pretty reliable.  They basically only check to make sure you didn't try to cheat somehow with referral exploitation or programs trying to modify the gambling feature they have.


-walletnotify on 6 confirmations instead of 1?

This is not possible with the current version of Bitcoin-Core (0.13.1).

Consider opening a issue (feature request) https://github.com/bitcoin/bitcoin or start implementing it yourself.


SSH is a generic protocol within which a user can deploy keys from a variety of algorithms, one of which is ECDSA (same as Bitcoin signatures).
The Ledger hardware wallet even has an application for its devices to perform SSH signatures using keys derived from the same seed used for cryptocurrencies.
TLS also has EC available as an algorithm so there might be a way to use your BIP39 seed for this as well.


What is the appropriate forum for technical discussions about Ripple?

There are a number of forums. Ripple Labs has an official forum that the developers read regularly. There's also a Google Ripple Server group.


Measuring levels of spammer participation on the Bitcoin network

I'll assume you're confusing the term "spammer" (someone who sends unsolicited email, or posts unsolicited advertising) with "hacker" (of which black hat ones might operate a botnet and mine cryptocurrency), so I've updated your question.

Bitcoin is generally substantially less worthwhile for a black hat hacker to mine with a botnet than an altcoin using scrypt (such as Litecoin). This is because Bitcoin hashing happens to be more efficient to run on GPU hardware, whereas scrypt is more efficient to run on CPUs.

IP addresses are not stored in the blockchain.

Not much is available in the way of statistics for Bitcoin users, so you'll probably find it difficult.

Pool operators can collect IP addresses of those connecting to their pool, so they may have some (or could potentially collect some) data useful for what you describe. Even then, tracking it would be difficult; it may become a cat and mouse type game like virus writers and anti-virus companies play, if the operator of a botnet becomes aware of what you're doing.


Is it possible to buy a prop of one of the "bitcoins" you often see in the pictures?

Casascius made physical coins with a private key attached (hidden with similar technology to scratch lottery cards). They were shut down in 2013 by the USA Treasury.

There are other companies who make physical Bitcoins but I cannot vouch for the services personally.

If it's memorabilia then a "used" coin is no problem. However it was possible to use non-polar solvent through an insulin syringe to peel back the Casascius safety seal to see the private keys without showing signs of tampering. This means it may be an issue to pay for ฿1 and find later your coins were stolen since your private key is known. If you buy a coin with ฿ associated with a Casascius coin private key I'd immediately transfer it to a "safe" address.


Why getinfo() and listchannels() inactive channel count differs?

It would appear that you have (or rather had them at the time you ran the commands) 6 channels that were funded, but not yet announced. This is most likely why your node sees them (getinfo) but gossipd doesn't yet (listchannels) since they haven't been announced just yet.


creating OP_RETURN script on bitcoin core console. i.e. with the help of commands

createrawtransaction has an option for data. That will create an OP_RETURN output with whatever hex-encoded data you want in it. So you would have a createrawtransaction command that looks something like this:

createrawtransaction '[]' '{"data":"deadbeef"}'


Best script/pseudocode to convert xpriv to xpub?

If you are comfortable with using the command line then libbitcoin-explorer is a great utility for converting your bitcoin HD keys. It even works completely offline.

Once you have bx installed, you can run the hd-to-public command like so:

$ bx hd-to-public xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
=> xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8

More info about the other HD Key related commands for libbitcoin-explorer can be found here: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-hd-to-public


What is the difference between digital signature and a digital fingerprint?

A "digital fingerprint" is a unique identifier that references some particular piece of data. Typically, the fingerprint is fixed in size and the information it references is much larger in size. In this case, a bitcoin address is a 160-bit digital fingerprint of a 256-bit public key created by hashing the public key twice.

The difference between a digital signature and a digital fingerprint is that anyone can produce a digital fingerprint while a secret key is needed to produce a digital signature. Digital signatures are used to prove that a particular piece of data was provided or approved by a particular party. Digital fingerprints are used to ensure that the data provided is the correct data.

When a typical bitcoin transaction is performed, the transaction includes a digital signature. It is not enough to ensure the digital signature is valid though, the signature must be made with the correct key. To determine that, the digital fingerprint of the public key used to sign the transaction is checked against the address. If they match, then the public key is correct, meaning the transaction was signed by someone possessing the appropriate secret key.


Official or default Bitcoin wallet for Android

I don't think the Bitcoin Foundation or any similar authority has designated an official or preferred Android app, not in the same way that Bitcoin Core is the "official" desktop client because it is the reference implementation.

But the most popular one seems to be Bitcoin Wallet by Andreas Schildbach.


Can I spend a coin sent to myself before it confirms?

Yes.  Unlike other transactions you don't need to wait for the confirmations.

From the code which selects which coins to use to fund a transaction in src/wallet.cpp:

bool CWallet::SelectCoins(int64 nTargetValue, [...])
{
    vector<COutput> vCoins;
    AvailableCoins(vCoins);

    return (SelectCoinsMinConf(nTargetValue, 1, 6, vCoins, setCoinsRet, nValueRet) ||
            SelectCoinsMinConf(nTargetValue, 1, 1, vCoins, setCoinsRet, nValueRet) ||
            SelectCoinsMinConf(nTargetValue, 0, 1, vCoins, setCoinsRet, nValueRet));
}

where SelectCoinsMinConf's 2nd and 3rd arguments are "number of confirmations a coin needs if it's from me" and "number of confirmations a coin needs if it's from someone else" respectively:

bool CWallet::SelectCoinsMinConf(int64 nTargetValue, int nConfMine, int nConfTheirs, [...])
{
    [...]
}

So what's happening is the code first tries to fund the transaction using only coins you sent to yourself which have at least 1 confirmation and coins from others with at least 6 confirmations.  If it can't find enough that way, it tries again but only requiring 1 confirmation on the coins no matter where they came from.  And if that also fails, it relaxes the requirement for confirmations on coins you sent to yourself.


Why does bitcoind say "error: couldn't connect to server" for the first few minutes of boot-up?

The first thing Bitcoin-QT does is verify that the data stored on the disk is valid. Among other checks this includes verifying the last 288 blocks (the past two days in expectation). This task involves a large number of signature checks and will take some time to complete. Only after the startup checks have successfully completed will the connections to the Bitcoin Network be established and only then the client will start listening for incoming JSON-RPC requests.


It depends precisely how secure you need to be. Generally speaking, the entire block containing the transaction and the next 100 block headers should be sufficient. The validation should consist of ensuring that the first block actually contains the transaction and is a valid Bitcoin block, the other 100 blocks form a valid chain, and all 100 blocks meet a reasonable difficulty target.

The easy way to create such a chain is to get the transaction confirmed and wait for all the world's miners to produce 100 blocks. Other than that, you'd have to find all 100 blocks yourself, which is an awful lot of work to do just to fake one transaction.

Note that this method would fail should the Bitcoin network's total hashing power ever fall below what the device expects as the real blocks wouldn't meet the "reasonable difficulty target". You do, to some extent, have to predict the future Bitcoin difficulty to make this work.

This assumes that having no central authority is a requirement. If you can accept a central authority, then that central authority can periodically issue a signed statement of the current minimum difficulty and number of blocks the device should accept. Updating this every year or so should be more than sufficient. That would allow you to wait for far fewer confirmations. 100 confirmations will take 17 hours or so.


How often should I call getblocktemplate?

One fundamental, expected way to make a valid template invalid: someone else finds a block, and it's time to switch.

You can technically keep incrementing "curtime" until it's 2 hours in the future, though my gut tells me I should try to avoid pushing "curtime" anywhere near that far into the future until after I've exhausted everything else.  I haven't spent too much time looking into GBT, but you should be able to make at least some changes to the coinbase data on the generation transaction (you probably won't have complete freedom, as I'm guessing there's a way for the pool to force things like /P2SH/ to show up in there for example) to get a different Merkle root.  People often call this the "extranonce".

As for when you should ask for a new template, immediately after the spot you quoted in the bitcoin wiki, it says this:

  If your template included a "longpollid" key, you can queue a request for a new template to be executed as soon as the pool decides you should change. This is the same as any other template request, except that you include the "longpollid" parameter that the pool provided in your request. If there is already a new template, the pool might respond immediately, so be sure not to depend on a delay!

In other words, you should be able to do a "long poll" request that won't return any data until the pool server decides for you that it's time for a new template.  You definitely shouldn't rely on guessing that "desired block interval" ought to be good enough.


Canadian bought BTC on cex.io in USD - how do I deal with them to not lose money with CAD-USD exchange rate?

Even the Canadian exchange places like quadrigacx or Einstein deal in US funds for the sake of trading.
You spend CDN to get US so you can buy and trade.
   If I could give you a piece of advive...  trade your bitcoin for LITECOIN before sending it to a different exchange place. Bitcoin will cost about $40 in network fees to send. Litecoin is pennies.
    After that  you send from your litecoin wallet on cex to your litecoin wallet on Quadriga.
Only ever send lite to lite , btc to btc etc...
        Go to quadriga and fund your account. Select litecoin. It will show your wallet address. Copy exactly.
Go to cex  litecoin waller. Hit "send litecoin" put the litecoin address that you copied from quadriga. And send funds.
You may get an email asking you to confirm.  Every site is different. It will take about 20 minutes. (6 confirmations)
It will then show up in quadriga.


Can I use Bitcoin to recieve funds from Egypt

Yes it is possible.

Steps.

1) Find a bitcoin seller in Egypt.

2) Buy Bitcoins in Egypt. Your Friend must provide a bitcoin address to receive the bitcoins.

3) You provide a bitcoin address to your friend where he sends the bitcoins.

4) You find someone willing to buy bitcoins with sterling in your location.

5) Sell your bitcoins and receive Sterling.

You both will need a bitcoin wallet. And a way to contact with a bitcoin seller/exchange.

You can do the exchange in person (ie, LocalBitcoins) or directly to your UK bank account using a service like Coinbase.


How does the structure of a segwit block differ from a non-segwit block?

A segwit block's coinbase transaction must contain an output with a commitment to the witness root hash, see BIP141.

  The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:

1-byte - OP_RETURN (0x6a)
   1-byte - Push the following 36 bytes (0x24)
   4-byte - Commitment header (0xaa21a9ed)
  32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)

  39th byte onwards: Optional data with no consensus meaning

  and the coinbase's input's witness must consist of a single 32-byte array for the witness reserved value.

  If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment.

At the transaction level, a segwit transaction must set the witness flag to 0001, and provide the witnesses before the locktime. A non-segwit transaction contains neither of these properties.

See Bitcoin Wiki - Transaction


full node bitcoin, l have a 32 bit pc,can I run a node with an SSD?

Most likely. This page has instructions on how to download and run bitcoin core. You can checkout the Cost and Warnings section to see if your machine is capable.

If you need to store the blockchain on an external ssd, you need to edit the bitcoin.conf file to point the datadir at your drives location. Here's more information on bitcoin.conf.


Can I send bitcoins with my mobile phone?

There are at least two actual clients for Android and half a dozen "thin clients" that connect to a bitcoin server at home. As the thin clients are kind of complicated installs, I recommend Bitcoin Wallet by Andreas Schildbach.
There are a few questions of security as both apps have no way (that I'm aware of) to import/export/backup wallets and it's uncertain what level of security is held on data Google keeps in the cloud, but for carrying a small amount of coin for daily use, both are viable options.

Not being an iOS person I can't weigh in on the features etc. of the various iOS apps, but a quick glance over the various projects seems to show an assortment of thin clients and no actual iOS-based bitcoind implementation.


Funds still showing in old Armory wallet/address after being sent+confirmed to new Electrum one?

It's not Armory that hasn't caught up, but your bitcoind that hasn't caught up. Armory works on top of bitcoind and gets all the block information from the local bitcoind node. It looks like the bitcoind node has about 50,000 blocks to catch up before Armory will notice that the bitcoin is gone. Just let bitcoind catch up (how long will depend on your network bandwidth and your computer's RAM/CPU) and you'll see it once the blocks catch up.


Can I run bitcoind without downloading new blocks?

Essentially, you want to run bitcoind while connected to the network to download all the blocks, then disconnect it from the network so it no longer downloads new data. There are several possible ways to do this, from least to most drastic:

Use the -proxy option to specify a proxy that does not exist.
Use a software firewall to prevent bitcoind from communicating with the network.
Run bitcoind in a virtual machine and turn off its network access.
Physically disconnect the machine from the network.


Why don't bitcoin escrow transactions require a third party?

Bitcoin escrow schemes that don't require a third party typically don't require a third party because that is one of their design requirements. It's obviously much easier to design an escrow system that does require a third party, so typically you would only design one that didn't if you had no choice.


Is 'nLockTime' equal to 'lock_time' in transaction data structure?

Yes, they are the same. nLockTime is the name used in the Bitcoin Core source code (e.g. here) , whereas locktime or lock_time might be more common in JSON input/output or other pieces of software. The Bitcoin Core RPC uses locktime for example, and blockchain.info uses lock_time in its rawtx/ endpoint


How the blockchain knows that its been tampered with?

Hashes don't actually 'change'. When you add a transaction to a block you are creating another block.

It's like an author published a book and then next year printed a new edition with an extra comma in the page 36 and the fans said he released a 'new' book. It doesn't make sense for books but for blockchain every bit counts.


How would multiple people send in one transaction?

Is it possible to have multiple inputs, from different people?

the bitcoin system doesn't know people - it is working with transactions, that move funds from address to address. Still the answer is "yes". You can create transactions, that spend funds from different addresses. To be more specific, we would talk about UTXO, but I think that goes beyond scope of the question, and the developers webpages have enough explanation (see reference below).
Exchanges create such transactions all the time, or also faucets. They (can) have multiple inputs, and multiple outputs as well.

  How would this be set up?

you would follow the specification :-)
A guided example is in  the Complex Raw Transaction section of the developer examples.


New to Bitcoin - Need help understanding the mining part

The biggest problem with developing a peer-to-peer payment system with no central authorities is preventing a double spend.

Say you're developing a payment system to allow people to pay each other widgets. If Alice has 10 widgets, she has to be able to pay 10 widgets to Bob. And she has to be able to pay 10 widgets to Charlie. But if she can do both with the same 10 widgets, the system is broken. So, somehow, Alice paying 10 widgets to Bob must stop her from paying those same 10 widgets to Charlie.

Bitcoin solves this problem with a mechanism called "proof of work". It's a bit complicated to explain, but the key point is that it requires an enormous amount of computational effort to be placed on either of the two payments. The one that has this computational effort is the one that "wins". The cost to put the computational effort behind both transactions would exceed the value of the transactions and you'd never catch up anyway because the winning transaction would be getting more and more proof of work (called "confirmations").

Because this computational effort costs money, Bitcoin needs some way to reward those who do it. They won't just do it out of the goodness of their hearts. Eventually, transaction fees will probably do this, but in the early days, there were too few transactions and Bitcoins weren't valuable enough for transaction fees to pay for the proof of work needed to secure the system.

The genius of Bitcoins is that the designer(s) solved two problems with mining. They added a "block reward" that goes to the miners to reimburse them for their computational effort. This not only solved the problem of how you pay for the computations effort needed to secure the currency before transaction fees can do it but it also provided an automated and predictable way to create the currency in the first place.


An output descriptor (note that output descriptor and wallet descriptor refer to the same thing) is a human readable string that represents an output script (a scriptPubKey) and everything needed in order to solve¹ for that script. Descriptors also have a bech32-like checksum which allows for the descriptor to be given to others with less risk of accidentally mistyping or losing some characters in the descriptor string.
Descriptors are unambiguous as to the public keys to use (derivation paths for extended keys are explicit) and the scripts to use. This makes them suitable for importing to other wallets without confusion. In contrast, traditional import mechanisms support only keys with special versioning to indicate the scripts to produce, and don't provide the derivation paths. This creates a situation where a user imports an extended key into a wallet but is unable to see their addresses because that wallet uses a different derivation path than the original wallet. Descriptors avoids this issue entirely by specifying the derivation paths (if any) and the scripts to produce.
A descriptor wallet is one which stores output descriptors and uses them to create addresses and sign transactions. By abstracting away address creation and transaction signing to a largely standalone module, such wallets can upgrade to using new address types much more easily.
For most users, the only visible effects will be in wallet import/export. Descriptors will only be shown during exporting, and descriptors should only be handled by the user when they want to import their wallet. Wallets that use descriptors internally shouldn't have any noticeable effect to the user.

¹: Solve - Solving a script means that one would be able to create a final scriptSig/witness with valid signatures if they had a private key. This means that all public keys and other scripts are available.


What is the difference between "time" and "timereceived"?

time is the best guess for the actual time a transaction took place. timereceived is the time at which the wallet received the transaction.
For the most part, both of these fields will be the same. Generally when you use a wallet, you will receive transactions when they are unconfirmed which is then both the time that the transaction is received, and the best guess for the time the transaction was made.
However there are a few cases where the time and timereceived will be different. This is particularly noticeable when creating a new wallet with imported data and rescanning the blockchain.
Suppose you import an address which has a transaction from 2 years ago. When your wallet scans the blockchain for existing transactions, it will learn of that transaction at the current time, so it sets timereceived to now. But that is not reasonable for a transaction that existed in the blockchain 2 years ago. So it will try to guess what time that transaction was actually made by looking at the timestamp for the block it is included in. That block's time becomes the time for that transaction. In this case, time and timereceived are not the same and more clearly represent what those times are.


I have some amount of bitcoin, how can i convert them to cash?

You can sell them on Localbitcoins , the idea is to find a local buyer and meet him face-to-face.


How is over-spending one block apart prevented?

When a node learns of a transaction, some validity tests are performed and if the transaction is not yet in the blockchain it knows of with the longest height and the transaction also is valid (i.e., not a double spend) then that transaction is added to that node's memory pool.

If a later transaction arrives at a node but is an attempt to double spending of a transaction that is either already in the blockchain with the longest height or is already in the memory pool, then that later transaction is ignored.

A transaction propagates to nearly all miners within seconds, so most miners would immediately reject your later double-spend attempt since they would already know of the earlier transaction.

Blockchain forks happen all the time (i.e., multiple times each day).  So it is entirely possible to have conflicts where a transaction is included in a block on one side of the fork but is not yet in the block (or blocks) on the other side of the fork.  Eventually one of the several competing blockchain forks will emerge as the longest chain and the transactions in that chain are the ones reflected in the Bitcoin ledger from then on.  That's why exchanges wait until three or six confirmations -- as it is technically possible for there to be variations between sides should a fork occur.

Attackers might use this temporary inconsistency in an attempt to defraud by employing a race attack or other approach.  This is requisite reading on the topic: http://en.bitcoin.it/wiki/Double-spending


bitcoind bulk import private keys to different wallets and update with one rescan

You really should use the newer importmulti RPC.

It lets you import multiple private keys at once (and since 0.18, also supports BIP32 derivation etc), and will do the rescan (if desired) once for all keys simultaneously.

If you have accurate birthday information for your keys (a lower bound on the time when the corresponding addresses might be first used on the network), importmulti will even only rescan the relevant part of the chain.


Beginner, how to get bitcoins to invest?

If you don't want to invest capital but still want to obtain some BTC, you will either need to earn it or be given it. Bitcoin faucets give a small reward for visiting the site, usually because of ad revenue the site obtains by the visits. The most reliable way to earn larger amounts of BTC would be to sell products or services in exchange for bitcoin (obviously selling products is similar to investing capital, but services such as freelance programming, etc. can pay well)


Coinbase outgoing transaction never changed destination account balance?

Blockchain.info must have missed a block or had some other complication with their database.

http://blockr.io/address/info/127SXekKqYsY6EbASqkvSZ4ZfF31qGKG93


Mining Rig is a computer system that is used for mining cryptocurrencies. This rig can be a devoted miner where it was appropriated, built and operated specifically for mining or it could differently be a computer that fills other needs, such as opearting as a gaming system, and is used to mine only on a temporary basis. "Mining rig" is a ideomatic metaphor for a single computer system that performs the compulsory computations for "mining".


relationship between bitcoin miner and verification of transactions

A miner can either verify transactions itself or assume that a transaction is valid as some nodes let him know they verified it.

In either case, the miner can enter the transaction in the block he is working on. Note that in pool mining the pool decides what transactions are included, while in solo mining your own bitcoind client does so.

An important thing to know is that miners only try to make a successor block for a block they think is valid. This means that when a miner generates a block with an invalid transaction on top of a valid block, other miners will not accept the new block. They will ignore it and continue trying to build a block on top of the last block they think is valid.

This way of working results a situation in which accepting invalid transactions and broadcasting invalid blocks is a waste of resources because your blocks will be orphaned and you will have to start all over.


Why was my full node knocked off the network last night?

As Nate Eldredge said, the block that you received is a Bitcoin Cash block which is invalid to Bitcoin Core. Because of this, your node banned the Bitcoin Cash node that sent you the block. However, it seems like the way that you have your node set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core thinks the connection came from your gateway instead of from where it actually came from. When your node banned the Bitcoin ABC node, it banned your gateway as it thought that was the bad node. This had the effect of then banning everything connected to you because they all connect through that gateway and the gateway was banned. The connections are back today because the ban is only for 24 hours.

I highly suggest that you make sure that the connections are properly being passed through so that this does not happen in the future. To ensure that they are passed through, if you use getpeerinfo (or the Peers tab of the Debug Window if you are using the GUI) and look at the IP addresses of all of the nodes you are connected to, they should not be the IP address of your gateway.


Is it possible to query a node for all addresses containing value?

Bitcoin-core (the full node implementation that makes up the majority of the network) does not keep an index of all addresses and balances, so without writing additional code to do the job, it is not possible. Bitcoin-core keeps track of coins via the UTXO model-- the idea of 'an address with a balance' is just an abstraction of this that makes for a more user-friendly interface.
Of course, you could write some code to create an index of addresses and their respective balances, or perhaps find an already-existing open-source block explorer project that accomplishes this.


Why did Bitfinex choose to have access to all of its customers' private keys?

However, I would assume it is poor practice for an exchanger to have a customer's private key. Please correct me if I am wrong.

It's generally not a very good idea, but a lot of exchanges do this.

Let's say that a customer has Bitcoins, and wants to trade them to the exchange for dollars. If the private key is held by the exchange, this order can complete instantly - it just changes two rows in the exchange's database. However, if the customer holds the private key, they need to transfer the Bitcoins to the exchange. Getting the first confirmation for that transaction could easily take an hour.

Of course, if you aren't going to make any trades in the next hour or so, you could withdraw your money into your wallet. The problem is that not many people bother doing this.

Some exchanges, like ShapeShift, hold customer funds for the minimum possible period of time. However, they take a risk, because when they lock in a price for the customer, they don't know for certain that the trade will complete. They might buy some cryptocurrency in anticipation of selling it to a customer, but then have to sell it at a lower price when the trade falls through.

If you want to get around these limitations, you need a way to move money to and from the exchange faster. (Both Sidechain Elements and the Lightning network come to mind, but I'm not aware of anyone using either in production at the moment.)


blk.dat files contain blocks data in raw format. Also a leveldb index is maintained that helps to quickly lookup blocks/utxo. You can find the details here and here.

Blockexplorers will not directly read these files. It is not safe for multiple process to access leveldb at the same time (blockexplorer and bitcoin node  process). Here is a brief summary of what a blockexplorer will do:

Create tables having indexes to store blocks/transactions/addresses
Do RPC calls/ listen to callbacks to bitcoind to get latest data
Store fetched data into tables
Goto 2.

Most of the commonly used blockexplorers are forked from the below opensource  code:

insight
bitcoin abe


Can an FPGA for mining be used to crack deterministic keys?

An FPGA can do anything, by definition (Field Programmable Gate Array) they can run any bitstream you care to write for a specific task. The BIP0032 wallets you're thinking of however are 128bit keys with significant key stretching, so not a chance in hell will you ever crack one. That's by design.


'The node is not in a connected state' error when trying to execute OP_RETURN transaction with NBitcoin

I think the problem is that there is only OP_RETURN, I remember seeing in the Bitcoin code that only OP_RETURN without anything else is forbidden.

Except that, your code looks like what is in my book
https://blockchainprogramming.azurewebsites.net/ so I'm almost sure it is the problem.

EDIT : You are crashing during Handshake, can you check Node.DisconnectReason ?


How to open a corporate account on Bitstamp?

If your (UK) business is in an area where you have specific regulations to follow for anti-money laundering, and you do, you will already know the answer. (If it is not in the UK, you may have to find out if dealing with UK-registered Bitstamp means you'll have to start complying with UK law and its requirements like KYC: Know Your Customer.) Otherwise,  the first answer is likely no and the follow-up questions are not applicable.

Commonly, KYC includes requiring a scan or photocopy of customer's photoid (passport or driving permit) and
of a proof of address (utility bill), and checking that they are not on a list of people the UK does not allow you to do business with.


Why the signature is always 65 (1+32+32) bytes long?

There are two different encodings used.

Everything in the Bitcoin protocol, including transaction signatures and alert signatures, uses DER encoding. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.

For message signatures, a custom encoding is used which is more compact (and more recent) and supports public key recovery (given a message and a signature, find which public key would have created it). The code you're referring to in the question is for creating such signatures.

A correct DER-encoded signature has the following form:

0x30: a header byte indicating a compound structure.
A 1-byte length descriptor for all what follows.
0x02: a header byte indicating an integer.
A 1-byte length descriptor for the R value
The R coordinate, as a big-endian integer.
0x02: a header byte indicating an integer.
A 1-byte length descriptor for the S value.
The S coordinate, as a big-endian integer.

Where initial 0x00 bytes for R and S are not allowed, except when their first byte would otherwise be above 0x7F (in which case a single 0x00 in front is required). Also note that inside transaction signatures, an extra hashtype byte follows the actual signature data.


What subjects do I need to study before I am capable of understanding the mathematical problem being solved in Bitcoin mining?

Your ASIC basically only does one thing: SHA256 hashing. It gets a block template, hashes it, compares the result as if it was a number to some target to see if it is less than the target, if not it modifies the block slightly, hashes again, repeat...

So all you need to understand is the SHA-256 hash algorithm. It is not overly complicated, you will need to understand some logical bitwise operations like AND and XOR, hopefully understand how bits, bytes, hexadecimal, etc. are all related, it involves some bit-rotations which should be mostly self-explanatory, how modulo works, and maybe a couple of other similar-level concepts. As a postgrad digital electronics engineer I expect most of these concepts are bread and butter to you, so you should be ok :)

Of course, that's just to read through how the algorithm works, understanding why certain things are done in the algorithm is much more complicated and would require a lot more reading about hash functions and cryptography. But understanding why something is done is not a requirement to use it.

Wikipedia page for SHA-256 which contains some pseudocode is found here: https://en.wikipedia.org/wiki/SHA-2


Import multiple watch-only addresses using importaddress?

The RPC interface doesn't generally provide any "batch mode" functionality.  If you want to import 100 addresses, call importaddress 100 times.  You might like to write a short script with a loop in some other language.

You should set the rescan parameter to false for all but the last address, so that you don't trigger rescanning 100 times.


I'd say there are number of issues at play here. If the system is "offline" then the only update you'll have to balances is whatever was last stored. The assumption here is both sources are trusted, and the system in the middle is trusted. Might as well make it a centralized asynchronous system. You'd have far more control and less reliance on 3rd party tools at that point.

The system proposed would be "nice" but a solution in the meantime would be to develop an internal ledger. You know party A, and party B. You know their balances, and you trust their transactions. This system assumes you know their keys as well, or can obtain them as needed.

Based on the most recent balance store your transactions in a normal DB. Running balance, again based off most recent information. Whenever the node is able to connect, update the current balances (trust but verify), check any previous transactions you may have submitted for failures (lack of gas, improper transaction, lack of funds etc), then process the transactions.

If there are A -> B and B -> A transactions then you could resolve transaction balances internally (assuming that is legal for what's intended). Otherwise you can put in all kinds of logic to resolve each transaction. To summarize:

Use an internal system for tracking what's what. What's been paid, what needs to be paid.
When node connects, get as much info as you can. Current balance, confirmed transactions from previous submissions, transactions that are still waiting to be confirmed. Identify transactions that outright failed for whatever reason (this is assuming a short 'up time' for connection with the node. It wouldn't stay connected long enough to see transactions hit the first block), still sitting in mempool (not enough gas to be picked up and go stale), etc.
Process based off the information above. Transactions will ultimately be resolved or unresolved. A FIFO can be used to resolve the oldest transactions, or if the ideal situation is to resolve the greatest number of transactions first regardless of age then a large transaction may get backlogged while many other transactions get taken care of.

This is all a matter of striking a balance of "trust" vs "timing". If i own 2 wallets, and i'm the only one with the keys, i could run every transaction in a back end system tracking what "it should be" and resolving it whenever i want.

The provided suggestion is a balance between available technology(and circumstances), security, and accuracy.


Is mining essentially just a way to randomly select the next winning miner?

Mining adds a certain level of commitment to the process.

If mining were free, a corrupt user could create thousands or millions of corrupt miners (for free) that would publish invalid blocks that made itself rich, and try to get even one of these blocks accepted.

The same is true of your "god-like" random selector:
Publish blocks, and hope you get randomly selected!

But mining is intensive: it costs money to setup a miner, and it costs electricity and networking to run a miner. You cannot fake thousands or millions of miners; each of them costs real money.

So the only way you can publish invalid blocks and hope to get rich is via a substantial investment.   The hash power of the network is so big now, that it is virtually impossible to setup a "evil" mining pool.  (If you succeeded, that would be a >51% attack)

The costs associated with mining ensure that there is a barrier to entry, and that "evil" miners cannot easily hope to overcome "honest" miners.  It ensures the integrity of the entire system.