"Lost" password to BIP38 encrypted private key, encrypter may be faulty (Bippy)

It turns out Bippy does have a bug in the encryption algorithm where it mixes up the public key compression flag. As pointed out, I posted this problem on reddit as well, and a solution has been posted there:

  Bippy is definitely doing something wrong.

  Technical Explanation

  BIP38 encrypted keys have 4 components (in the simplest case).

  The first two letters of the key, 6P, are a marker that say this is a BIP38 encrypted key.

  The next letter, Y in this case, specify some attributes of the key. In this case it says "This is a simple BIP38 key, and the public key should be compressed."

  The next couple letters (4 bytes in the hex representation) specify a "checksum". We'll get back to this.

  The rest of the key is the real meat of it. It's the encrypted private key. That's what we care most about.

  Now let's get back to that checksum. The checksum is 4 bytes derived from the Bitcoin address associated with the original private key. A big caveat here is that there are actually two Bitcoin addresses associate with a plain Bitcoin private key. One is based off the compressed public key, and the other the uncompressed public key.

  That's why BIP38 encrypted keys specify whether they are using the compressed or uncompressed address.

  In this case, Bippy spit out a Y which means it used the compressed address. In your screenshots it even says as much. BUT here's where the problem is.

  When we check the checksum Bippy spit out, it doesn't match with a compressed address. But if we use the uncompressed address, it matches! So Bippy says it's using the compressed address, but it's actually using the uncompressed address.

  So Bippy definitely has a bug where it's using the uncompressed address, but saying in the resulting BIP38 key that it used the compressed address.

  This isn't too big a deal. I'll discuss this after the non technical explaination.

  Nontechnical Explanation

  Bippy is encrypting correctly, but it's screwing up its encoding of the encrypted key. It's saying it used public key compression when actually it didn't. This isn't a huge deal.

  Solution

  So, the good news is that it looks like, other than that minor bug, Bippy is encrypted the important stuff correctly. It should be possible to take your "lost" Bippy key and recover the private key from it. Assuming your password is correct.

  I should be able hack up my script to take care of that for you. I'll to to work on that and get back to you. (I need to fold in some Base58 encoding/decoding into the script and make it a bit user friendly for ya ;) ). The code will be quite simple Python code, so you can do a cursory glance to be sure it doesn't do anything evil.

A python recovery script has been supplied as well, available on github - all credits to fpgaminer


You're users are not in control of the private keys, so you do not need to lock them via the Bitcoin protocol. This is just a simple permission feature you should build into your system using a database. If a user "buys from you" then update a field in your database for that user, for example the database field could be called locked and then you would have it changed to true.  Then make sure that you build your system to check this field is false every time prior to withdrawal.


Is there a way to mine with many graphics cards without having a PC for each one (or two)?

I have found that the cheapest way to hold many cards is to put them in old motherboards.  I have been buying motherboards off Ebay for $45, getting a $5 processor, a $100 PSU and connecting 4 cards per rig.  I currently have 6 of these rigs running and they are great.  As for heating I have built custom cases for my cards so they don't overheat.  Using this method I've brought the cost to run each card down to about $50.  In other words, it will cost about $50 per card to put it into a computer if you build your own off Ebay.

Another option, which is definitely more expensive but probably the type of thing you were hoping to find is a PCI Express Switch.  These things exists and are how big companies can connect 20+ GPUs to a single computer, but they are prohibitively expensive in most cases.

Below is an example of my mining tower, if you would like more information on exactly what I buy and the economics behind it please don't hesitate to leave me a message.


How safe is Nicolas Dorier's BCCSpliter?

The readme file pretty much explains everything step by step.

But if you don't have much technical knowledge, the best one to use will be a wallet with some GUI. I suggest you to use Electron Cash.

But before using your private key of the BTC addresses, move those BTC to any other addresses, and then only use the private keys in this software (just a precaution).

You can also import multiple private keys together in this software.

P.S. I cannot comment due to the reputation limit right now, hope this helps you somehow.

Edit: Use precaution while using Electron Cash, as it is as of writing this answer is not much tested and have bugs.


What is the size of different types of channel funding/closing transactions for the Lightning Network?

The size of a transaction is no longer relevant. What matters is the weight (which is based on size), especially because LN uses segwit which has different weight values for segwit spends.

The expected weights for the commitment transactions and HTLC success and timeout transactions can be found here: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights.

The weight for the funding transaction is harder to know as that entirely depends on the inputs being spent and that is dependent on the sender. Since the inputs and their signatures make up the vast majority of a transaction, it is impossible to say what weight funding transactions will have as they will basically all be different.


Does input and output size vary by address type?

Both outputs and inputs differ in size depending on the address format.

P2PKH outputs are 34 bytes and P2SH outputs are 32 bytes.

P2PKH inputs are 148 bytes (180 bytes for uncompressed keys), and P2SH inputs are of variable size depending on the redeem script they need to fulfill. For example, a 2-of-3 multisig P2SH input (a very common P2SH use) has 297 bytes.


Manually create a transaction to spend the output of a P2SH tx

The redeem script is part of the scriptSig for the input you are trying to spend. Here is the format for a P2SH transaction:

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

The script is hashed and compared with the script hash in the scriptPubKey.


How many peers do you need to securely synchronize with the blockchain?

One! Your full node will check every transaction and every block for validity while synchronizing. You therefore can be sure that whatever blockchain data your node accepts follows all rules of Bitcoin. If you are provided the correct blockchain, a single node will be able to provide all data for you to catch up with the network's blockchain tip.
That said, your node will accept any data that follows all rules of Bitcoin. If an attacker knew that you were going to synchronize from scratch, they managed to sybil your node, they could attack you in two ways. First, they could withhold data from you, i.e. not give you the complete blockchain. The attacker could use this to set you up for a doublespend, by sending you money that they've already sent somewhere else in a block that they didn't tell you about. This is easy to defend against, by requiring confirmation before accepting payments or by verifying your local blockchain tip against the network's via third party resources such as blockchain explorers.
The second attack would entail feeding you a series of blocks that are not part of the most-work blockchain. This would require an immense amount of work as the blocks would have to adhere to the current network's difficulty level to pass your full node's verification. These blocks would have to be tailored to an attack on you, to include one or more transactions that send money to you that the attacker wants you to be believe to be valid. Mining valid blocks that are not part of the most-work chain is an investment on par of finding the same number of blocks in the most-work chain. Unless you're routinely accepting very large payments with few confirmations, you are not a likely target to such an attack on the Bitcoin blockchain. Note that some altcoins have very low difficulty levels and the cost of creating valid blocks would therefore be significantly lower.
The latter two scenarios are why generally Bitcoin nodes will connect to eight peers (and SPV nodes usually to four) and compare all of these peers' information about their best blockchain tip. Your node will still only download each piece of blockchain data a single time (as it can verify that it is part of the most-work blockchain).


Explanation of what an OP_RETURN transaction looks like

Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN.

Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they could take advantage of the irreversibility of the blockchain. Imagine for instance you wanted to write a contract and place it in an unchangeable location that at any future date one could go back to verify it existed. You can do this by using the blockchain. You add some bits to the transaction's scriptSig value that don't alter the end result of running that script, but allow you to store information like “I hereby declare to give asset A to address XYZ at time UNIX_TIMESTAMP”. There were even stranger ways people would add extra bits, like including it in the BTC value of an output. Some members of the community did not like this, as they saw these extra bits as polluting the blockchain. The extra bits were a network efficiency concern because more bits meant larger block chains and more of an onus on those who are running full nodes, and it was also a community consensus concern because they thought “we all implicitly agreed to store financial data in the blockchain, which is important to everyone, but we did not agree to store data like small text messages and invoice text”.

To reach a middle ground in these opposing views, the core-developers made the opcode OP_RETURN a valid opcode to be used in a bitcoin transaction, which allows 80 arbitrary bytes to be used in an unspendable transaction. A good explanation of this can be found here:

https://bitcoinfoundation.org/bitcoin/core-development-update-5/

Later in February 2014, the bytes count was reduced from 80 to 40 bytes. This change is documented in the link below. Note that in this pull discussion we learn that no more than one output with OP_RETURN can be included in a single transaction:

https://github.com/bitcoin/bitcoin/pull/3737

Now that we’ve got the reason behind OP_RETURN down, let’s look at an example of OP_RETURN. I used chain.com’s API to find a transaction which has an OP_RETURN in its scriptSig. That tx’s hash is

8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684

Make sure you are connected to a fully-loaded bitcoind node, and run this command:

$> bitcoind getrawtransaction 8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 1

which will give you this output:

{
"hex" : "0100000001c858ba5f607d762fe5be1dfe97ddc121827895c2562c4348d69d02b91dbb408e010000008b4830450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a0141045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4ffffffff020000000000000000156a13636861726c6579206c6f766573206865696469400d0300000000001976a914b8268ce4d481413c4e848ff353cd16104291c45b88ac00000000",
"txid" : "8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "8e40bb1db9029dd648432c56c295788221c1dd97fe1dbee52f767d605fba58c8",
        "vout" : 1,
        "scriptSig" : {
            "asm" : "30450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a01 045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4",
            "hex" : "4830450220446df4e6b875af246800c8c976de7cd6d7d95016c4a8f7bcdbba81679cbda242022100c1ccfacfeb5e83087894aa8d9e37b11f5c054a75d030d5bfd94d17c5bc953d4a0141045901f6367ea950a5665335065342b952c5d5d60607b3cdc6c69a03df1a6b915aa02eb5e07095a2548a98dcdd84d875c6a3e130bafadfd45e694a3474e71405a4"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.00000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_RETURN 636861726c6579206c6f766573206865696469",
            "hex" : "6a13636861726c6579206c6f766573206865696469",
            "type" : "nulldata"
        }
    },
    {
        "value" : 0.00200000,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 b8268ce4d481413c4e848ff353cd16104291c45b OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a914b8268ce4d481413c4e848ff353cd16104291c45b88ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1HnhWpkMHMjgt167kvgcPyurMmsCQ2WPgg"
            ]
        }
    }
],
"blockhash" : "000000000000000004c31376d7619bf0f0d65af6fb028d3b4a410ea39d22554c",
"confirmations" : 2655,
"time" : 1404107109,
"blocktime" : 1404107109
}

Now, look at this transaction’s list of outputs, in particular the 1st one. By referencing the Bitcoin Wiki’s page on Script, Bitcoin’s stack-based programming language, we can see here that the OP_RETURN opcode is represented by the hex value 0x6a. This first byte it followed by a byte which represents the length of the rest of the bytes in the scriptPubKey. In this case we see the hex value Ox13, which means there are 19 more bytes. These bytes comprise the arbitrary less-than-40 bytes you are allowed to send in a transaction marked by the OP_RETURN opcode. If you pop the message bytes into a UTF8 decoder, you’ll see that

636861726c6579206c6f766573206865696469

becomes “charley loves heidi”. Aw! It’s almost like a digital version of a couple’s romantic heart tree carving. Now you understand at a byte level how OP_RETURN is supposed to work. You can write software now that searches for the OP_RETURN opcode in an output’s scriptPubKey, and use it to verify a contract or some other digital asset.


How can Bitcoin solve societal problems caused by capitalism?

Bitcoin itself, although conceived from an ideological background doesn't have an agenda. It is a tool. It will not solve societal problems by itself, but might help alleviate some issues, by providing competition to current solutions. Especially, wealth distribution in Bitcoin itself isn't better than in other currencies (see e.g. Business Insider on Wealth Distribution in Bitcoin, BitcoinTalk on Distribution of Bitcoin Wealth).

International Remittances

Bitcoin enables its users to send money for minuscule fees around the globe. This could be especially beneficial to foreign workers that want to send remittances to their families in developing countries.

Currently, they are dependent on expensive services such as Moneygram or Western Union and lose up to 15% of the sent money in fees. Additionally, the recipient needs to go to the next money transmitter shop to pick-up the money. In many instances this is a trip of hours.

The Unbanked

Bitcoin doesn't require its users to have a bank account, as any form of internet access is sufficient to send and receive Bitcoin. Today, there is an enormous number of people without bank accounts. For example there are about 10 million unbanked or underbanked households in the US. In developing countries more than 50% of the populations are unbanked, women more so than men.

Without a bank account, you are either unable to use or significantly disadvantaged regarding a wide-range of services, such as credits, saving, insurance, payment for contracts, and internet commerce. See for example: Guardian on mobile banking for the unbanked.

Bitcoin could provide an easy access and cheap payment system for many of these services. It could be significantly cheaper than current payment systems such as M-Pesa, and have additional advantages by not being centrally run.

Censorship

No user can be locked-out of Bitcoin. On the other hand, it is well known for such things to happen in centralized payment systems for various reasons: eBay and Paypal exports Embargo, Paypal blocks donations to Diaspora. This is especially important for protest movements that might be shut-down by their government, think Wikileaks, Occupy Wallstreet, or Social equality movements in repressive states.


How do you check the validity of a signature while only having the hash of the public key

When an output is spent, the corresponding public key is disclosed and used in the verification.


What could be the impact of the distribution of "tainted" Bitcoinica coins?

I don't think there's really any need to do this to evade "Bitcoin police". Bitcoins are fungible and one is as good as another. Any attempt to track tainted Bitcoins is, at least in my opinion, doomed to fail.

[Imagine] if the FBI regularly published a list of serial numbers of currency that would no longer be honored. Banks would refuse to accept bills on the list, and soon so would grocery stores and so on. That hundred dollar bill you got from the bank, now sitting in your wallet, could appear on that list at any time because the person who deposited it at the bank right before you withdrew might have stolen it.
Think about what using currency would be like in such a world. Could you even have ATM machines? In fact, it would be the death of cash -- forcing people to use cash only for small amounts of money they could afford to lose. Such "tainting", if it hit the Bitcoin world, would similarly be the death of Bitcoin if it caught on in any significant way. - Tainted coins - Who dictates that a coin is tainted?

This also suggests an interesting way to defeat any attempt to taint Bitcoins, assuming such an attempt wasn't doomed anyway. Just take a chunk of the tainted coins and start transferring them to random, active accounts. The standard client doesn't make it particularly easy to quarantine coins nor does it hold newly-received coins separately from old ones. So when you make your normal payments, you pretty much can't help but spend some of the coins you received unsolicited. Soon lots of innocent users would be spending "tainted" coins and innocent merchants would be redeeming them at exchanges, which have to resell them.


ripemd160(sha256(publickey)) - Where am I going wrong?

moshaholo has the right answer, but not quite the right code.

>>> publickey = '02218AD6CDC632E7AE7D04472374311CEBBBBF0AB540D2D08C3400BB844C654231'.decode('hex')
>>> s = hashlib.new('sha256',    publickey).digest()
>>> r = hashlib.new('ripemd160', s        ).digest()
>>> s.encode('hex')
'ea571f53cb3a9865d3dc74735e0c16643d319c6ad81e199b9c8408cecbcec7bb'
>>> r.encode('hex')
'5238c71458e464d9ff90299abca4a1d7b9cb76ab'

Notice that publickey, s, and r are all binary byte strings (because .digest() is being used instead of .hexdigest()). The only reason to convert them to hex-encoded strings is for display purposes. You can display them directly if you like, but it's not pretty....

>>> publickey
'\x02!\x8a\xd6\xcd\xc62\xe7\xae}\x04G#t1\x1c\xeb\xbb\xbf\n\xb5@\xd2\xd0\x8c4\x00\xbb\x84LeB1'


What is SPV mining, and how did it (inadvertently) cause the fork after BIP66 was activated?

SPV mining is the term commonly used for 'less-than-full-node-validation' mining. It usually means that miners skip the verification of the block and the transactions within, and immediately start mining a new block referencing the just-solved block header. However, since they don't know what is in the last block, they have to mine without any transactions (except for the coinbase transaction), to be sure that they don't mine a block with transactions that conflict with transactions in the previous block.

After BIP 66 became enforced, about 5% of the network was still solving version 2 blocks (BIP 66 enforces blocks use version number >= 3). One of the miners in this 5% solved a block with version 2, and if everyone had been doing full validation, then their block would have been ignored and replaced by a version 3 block. That is what was supposed to happen.

But, unfortunately, a few pools (F2Pool was the biggest one, I think), started mining a new block that referenced the invalid block header without verifying the transactions in it or that the new header used a version number of 3 (as just became enforced). Miners will sometimes directly connect their full nodes or monitor each other's work APIs to see when another pool has solved a block, so that they can start working on a new block as quickly as possible. In this case, a few pools heard that BTC nuggets solved a block by listening to their Stratum API, and started mining on it. They didn't even have the block header, just the hash of the block header.

https://en.bitcoin.it/wiki/July_2015_Forks#Invalid_Block_Hashes shows the invalid blocks:

0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99 mined by BTC Nuggets (98 non-coinbase transactions)
0000000000000000155f2519d35cd5d2869900bcc5093594b27763a0315390b4 mined by F2Pool (0 non-coinbase transactions)
00000000000000000cb7a20ee4e199e347ad7369936abae53a1518efa531ec61 mined by F2Pool (0 non-coinbase transactions)
00000000000000000966d65e0fd87d1d5a8f154a2c955816c28e2006e381aa18 mined by AntPool (0 non-coinbase transactions)
00000000000000001301bfd6f566a421c7eeba103d09b312032ca065cb185de7 mined by F2Pool (0 non-coinbase transactions)
000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436 mined by F2Pool (0 non-coinbase transactions)

One of the Core Developers, Gregory Maxwell, also posted an explanation here, which you may find useful.


question on Armory bitcoin wallet scripting

Have you seen this page on the Armory website? It describes how to do what it is you appear to be asking to do.

First you import everything from armoryengine.ALL.

You have PyBtcWallet().readWalletFile(filename) to get a wallet object. Then you can do things with the wallet object.

You can also use TheBDM (Block Data Manager) to register callbacks for certain signals, such as new blocks.


What is the formula to calculate the length of a merkle tree?

The length of a merkle tree is the sum of a series starting with the number of leaves, halving (rounded up) on every step and ending with 1.

Here is the algorithm for calculating the length of a merkle tree from the number of leaves in JavaScript.

function getMerkleLength(leafCount) {
  // Input must be a positive integer or zero
  leafCount = Math.abs(parseInt(leafCount));

  var merkleLength = 0, currentLevel = leafCount;

  // Most merkle tree implementations return a null hash for empty lists, so the
  // length in that case would still be one.
  if (leafCount <= 1) return 1;

  // Loop
  for (;;) {
    // Add the current level to the length
    merkleLength += currentLevel;

    // If the current level is the root, we are done
    if (currentLevel == 1) return merkleLength;

    // Each level contains half the hashes of the last one and if there is an
    // odd number of leafs, the last hash is duplicated
    currentLevel = Math.ceil(currentLevel / 2);
  }
  return merkleLength;
}

Edit: I like readable code, but just for fun, here's the equivalent short version:

function getMerkleLength(leafCount) {
  for (var len = 0, i = ~~leafCount; i > 1; i = ~~(i/2+.5)) len += i;
  return len >= 2 ? ++len : 1;
}

Edit 2: And a C version for good measure.

typedef unsigned int uint;

uint getMerkleLength(uint leafCount)
{
  uint len = 0, i;
  for (i = leafCount; i > 1; i = (i+1)>>1) {
    len += i;
  }
  return len >= 2 ? ++len : 1;
}

void main() {
  uint i;
  for (i = 0; i <= 100; i++) {
    printf("%u: %u\n", i, getMerkleLength(i));
  }
  printf("%u: %u\n", 5000, getMerkleLength(5000));
  printf("%u: %u\n", 99999999, getMerkleLength(99999999));
}


Get transaction history of address using electrum commands

You can calculate the fee by taking the sum of the value of the transaction inputs and subtracting that from the sum of the value of the transaction outputs. The fee is really just the leftover amount of a transaction that is not specifically sent as an output.


How to handle multiple transactions from the same account(address)?

Confirmation concept is generally useful for the counterparty to be sure that the transaction through which he has received the BTC cannot be reversed. Nothing stops you from creating a new transaction referencing the outpoints (txid and n) of the transaction through which you just spent your 1BTC, if you do not plan on changing the previously broadcasted transaction by say a higher fee. Either both transactions can get mined in the single block, or the second transaction can get mined in block after the first transaction has been mined.


What are the ways to create an offline Ripple wallet?

There are two components of making a Ripple wallet offline:

The blob vault
This is what stores the private key that controls your wallet. Other people can try to guess your username/password over the network, and if the blob vault isn't trustworthy, then it can do a much faster attack against it.
Install instructions: There is an install script included (serversetup.sh), but it will only work on Debian-based systems. You can get it to work on others by installing node, npm, and mysql server. Be aware that you also need to edit the script and replace PASSWORD with your actual mysql root password.
The ripple client itself
Copy it to a local webserver, and point your brower at it.

Be aware that you need to be online to see the balance of your Ripple wallet.


Does it make sense to design a mutable blockchain?

I agree more context is needed to provide a more directly meaningful answer.

But in general: a blockchain allows users to interact without trusting a central authority, instead they verify the system’s state on their own. As a user, I can verify that I own some amount of bitcoin by running a node, and seeing the transactions that paid me as confirmed in the blockchain record. I know that the network’s rules do not allow those coins to be moved unless a transaction is signed by the valid keys (which I control). If the system allows mutability, then how confident can I be that the transaction which paid me will not be changed in the future? With an immutable blockchain, the energy spent on POW mining helps guarantee this, but if mutability is allowed... ??? How can I be sure?

If some form of mutability can be added while preserving this factor of trustlessness, then maybe a ‘mutable blockchain’ is reasonable. But I am yet to see such a proposal. If the user must trust a central authority to not change the system, then using blockchain architecture is superfluous.

In reality, I suspect in most cases a ‘mutable blockchain’ would be an inefficient way to implement a database, albeit one that can be dressed up in marketing buzzwords and sold to customers more easily due to the ‘blockchain hype’.

  But I personally fail to grasp any advantage of using a blockchain design if you are discarding immutability. Am I missing something here?

Advantage: customers love blockchain hype, so they’ll be more willing to buy what you’re selling.

I’m sorry to say, but I think your intuition is correct. Frankly, such projects seem either misguided, or scammy to me.

EDIT: perhaps worth mentioning as well: allowing a central authority to alter the blockchain record creates a monstrous security risk. No matter how well intentioned or benevolent the authority is, an attacker targeting their system of control represents a huge existential risk to the network. There is no such thing as a secure backdoor that only ‘the good guys’ can access.


Testnet: mandatory-script-verify-flag-failed when doing OP_RETURN


How does blockchaininfo find out the difficulty?

Blockchain.info definitely has a client installed on their servers, that's where they get all the block data from. I heard they're using a fork of BitcoinJ.

In the Bitcoin-qt daemon, you can get the difficulty of the latest block with the getdifficulty command, and you can get complete information about every block, including the difficulty, with getblock.


Signature digital algorithm in bitcoin, to what will it change in the future?

There's no consensus about the best post-quantum crypto encryption/authentication algorithms, but NIST has a competition to choose the best post-quantum crypto algorithms that are asymmetric (where public key and private key different). Surely there's enough time to wait for the competition to end before spending any effort on post-quantum cryptocurrency (Exceptions: qBitcoin, which is impractical, and Bitcoin Candy, which has no progress)


Creating An Altcoin: How to Lower or Increase Confirmation Times?

See the variable nTargetSpacing.  The difficulty adjustments will try to steer the average block time towards this value (in seconds).

You can't change this at runtime.  In fact, you can't easily change it at all once you've released your coin.  All clients on the network need to agree on this number, since it is used to calculate the required difficulty.  If you change it after release, then there will be a disagreement between old and new clients as to whether various blocks are valid, and your coin will have a hard fork.


Bitcoin mining by using solar energy. Is it possible?

It largely depends on what machine you want to power with those solar panels. You're definitely going nowhere with GPU based mining. As PCs consume a huge lot of energy, and those who don't, are equipped with Atom and Intel graphics, meaning mining won't get you far with that equipment.

However, it may be possible to run a USB ASIC miner based on a Raspberry Pi. I think those kind of machines consume very little energy. However, you may also need an Internet connection, but I'm assuming you already have a router you can connect to.

In that case, I'd buy one Raspberry Pi for each USB ASIC stick you want to buy.

The initial cost may be a bit hefty, though, and I'm not sure the performance would be that great, because there's just so much hashing power already in the Bitcoin network.

I'm sure you're better off mining Litecoin, Dogecoin or Feathercoin anyways. But well, there's no USB ASIC miner for scrypt cryptocurrencies, so you're out of luck for those alts.


Can I recreate a wallet using on my priv/pub keys only?

Yes, you can create a wallet with your key and will have access to the coins at the key's address.
Since a wallet typically contains many keys (=bitcoin addresses), however, you will not be able to reconstruct the whole wallet file.


There is no single entity responsible for ensuring the rules of the protocol are not violated. Rather, bitcoin is a decentralized network, so all participants must adhere to the protocol’s rules, or else the network will ignore them.

This is accomplished by a network of full nodes, that relay and validate all transactions and blocks against the network’s rules. All of the nodes together form the decentralized network, so to join the network you must adhere to the rules defined by the node’s code.

  The market forces behind the supply and demand of bitcoin

This will determine the price, but the price will not affect the ability of participants to violate the networ’s rules, nor will it ensure that rules are not violated. The rules must be followed whether the price is $1 per bitcoin, or $1 million per bitcoin.

  Miners

Miners work to secure the blockchain record, they will validate transactions in the same way other (non-mining) full nodes do, and they will ensure only valid transactions are added to the blockchain.

  Consensus of the miners

Same as above. Note that even if a group of miners decided to violate the network’s rules, then the network (full nodes) would simply ignore any new (invalid) blocks found by those miners.

  Developers of the bitcoin protocol

The developers collaboratively write and refine the code that runs the network, but this does not give them absolute powers to violate or change the rules. Their code works to ensure that everyone involved in the network is behaving, and that any misbehaving nodes are banned.


What are the analogous steps between transfer of value from buyer to seller with traditional P.O.S. solutions vs. with bitcoin

I think the answer is that a credit card company is vouching for you when you make a purchase. The seller does not know you, but they know the credit card company, and they know the credit card will give them their funds. The credit card company in turn knows you, and has deemed you credit-worthy. This is why it's called "credit" ... from the latin credere: "to believe" or "to trust". The credit card company believes that you will pay your bill at the end of the month.

Bitcoin is like cash... except that handing over physical cash takes a fraction of a second, but handing over digital cash takes approximately 10 minutes in the case of bitcoin (less with alt coins that add to their block chains at a faster rate).

The seller could decide that if this is a repeat customer (who has bought successfully with bitcoin once or more times before) to extend credit themselves, and just assume the transaction will be validated. Then, at the time of sale, the transaction will be just as quick as a legacy credit card transaction would.

Some alt coins are building in reputation via marking (such as Bitmark) which will go a long way towards allowing sellers to make immediate credit decisions even from buyers new to them. I think this is somewhat analogous to a built-in FICO score for a particular wallet.


Does MuSig have the same security as 2-2 multisig?

Yes or no, depending on your definition.

You are right that the expected time to forge a 2-of-2 multisignature is twice that of a single signature, because you obviously need to use your forger algorithm twice.

However, in practice such constant factors are ignored when describing security levels. For example, typically ed25519 and secp256k1 are placed in the same group of 128-bit security, despite the fact that secp256k1 needs on average 4x more iterations of Pollard's rho algorithm to break the DLP. On the other hand, due to secp256k1's efficiently computable endomorphism, individual iterations of that algorithm are 1.7x faster than what would be expected otherwise.

Furthermore, the unit they're specified in is vague. When talking about ECDLP, the security levels is usually specified in terms of the number of elliptic curve multiplications. But an EC multiplication is not a trivial thing, nor is its performance identical across curves. However, when talking about things in the order of 2^128 a factor 10 here or there only changes the exponent by 3.3. It gets even fuzzier when you take into account specialized hardware that could be built for certain tasks, making it even hard to compare.

The point is that we don't care how long things take for an attacker. We only care that they're so long that no attacker could conceivably use them to pose a real threat.

If it takes too long to forge two signatures, it very likely also takes too long to break one.


It is a number designed to protect new clients from accepting fake blockchains when they initially are syncing, if an attacker managed to segregate them from the network. As the name suggests, it's the minimum amount of total work a chain must have before the client considers it valid. It is updated to a higher number at every release, based on the total work in the blockchain at the time of that release (the hex format is more compact and consistent with other code than say a decimal number)


Issues connecting a Bitcoin-Qt Wallet to a local node

It might be you need to add some lines in the bitcoin.conf file on the Raspberry Pi.  This was taken from the github repo example of the bitcoin.conf file

##############################################################
##            Quick Primer on addnode vs connect            ##
##  Let's say for instance you use addnode=4.2.2.4          ##
##  addnode will connect you to and tell you about the      ##
##    nodes connected to 4.2.2.4.  In addition it will tell ##
##    the other nodes connected to it that you exist so     ##
##    they can connect to you.                              ##
##  connect will not do the above when you 'connect' to it. ##
##    It will *only* connect you to 4.2.2.4 and no one else.##
##                                                          ##
##  So if you're behind a firewall, or have other problems  ##
##  finding nodes, add some using 'addnode'.                ##
##                                                          ##
##  If you want to stay private, use 'connect' to only      ##
##  connect to "trusted" nodes.                             ##
##                                                          ##
##  If you run multiple nodes on a LAN, there's no need for ##
##  all of them to open lots of connections.  Instead       ##
##  'connect' them all to one node that is port forwarded   ##
##  and has lots of connections.                            ##
##       Thanks goes to [Noodle] on Freenode.               ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Listening mode, enabled by default except when 'connect' is being used
#listen=1

# Maximum number of inbound+outbound connections.
#maxconnections=

#
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
#

# server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands
#server=0


What sort of calculations do the miners have your computer do?

The calculations are fairly meaningless, it's a pot luck type process so that it is fair for all. They aren't /useless/ though - because they are what power the vast and incredibly secure Bitcoin network.

Edit (elaboration):
Bitcoin hashing is sha256(sha256()) (i.e. sha256 twice.. just for extra protection from sha256 attacks)..  the input to the sha256 algorithm contains various data that identifies the "solution" to the next block.. so it'll have data like the previous block hash, a timestamp, and a hash for transactions included in the block.

If a miner finds a valid solution then the node verifies and accepts it and broadcasts it to other nodes. If enough nodes receive and verify this solution then it becomes a block and all miners move on to the next block solution. Because mining is random there is no historical data lost when someone else finds a block - every miner has the same chance (proportional to their hash rate of course) - they just repeat sha256(sha256()) over and over. In order for a solution to be valid it must fit all previous blocks and must be a number low enough (defined by the current network "difficulty" level).


If newly generated coin disappear, will that affect the total supply?

The way for newly generated coins to "disappear" is if the corresponding block is orphaned, i.e. a different branch of the block chain becomes the longest (in terms of work) which does not contain that block.  The total money supply could be affected slightly in the short term, if the new dominant branch is longer or shorter (in terms of blocks) than the previous one, and thus contains more or fewer block rewards.  It's not affected in the long run, since the money supply limit is in terms of total coins on the dominant branch.

In other words, if the orphaned block was at height 503567, then the new chain will (eventually) contain a different block at height 503567, and this block will have the same reward as the original orphaned block.  So the economy still contains the coins that correspond to the block reward at height 503567, they have just been paid to a different miner.


What mining performance can we roughly expect from the Intel SHA extensions of the upcoming Skylake processor architecture?

Let's try to make a rough estimate.

Intel's article Intel SHA Extensions gives some details on these instructions as well as sample code.  The main feature is the sha256rnds2 instruction, which performs two rounds of SHA256, out of the 64 rounds that are needed to hash one 64-byte block.  A Bitcoin header is 80 bytes long, so that's 2 blocks, and because the mining algorithm is SHA256D, we need to do it twice.  So we need to execute sha256rnds2 128 times to perform one Bitcoin hash.

I'm no expert on modern CPU architectures, but I would suspect a complex instruction like this would take more than one clock cycle; nonetheless, let's generously suppose it doesn't.  Since each round depends on the outputs of the previous, these rounds probably have to be executed serially (on each core), so not much parallelization can be done.  But let's very generously assume there are resources that can be shared, so that the CPU can execute two sha256rnds2 instructions per clock cycle.  Let's also generously assume that all the ancillary code needed to set up for sha256rnds2 can be pipelined and doesn't require any additional clock cycles.  So it takes 64 clock cycles to perform one Bitcoin hash.

Now, how fast can we run the clock, and more importantly, how much power would be used?  Since power consumption is paramount, let's suppose that we would want to use a mobile CPU.  The Wikipedia article on Skylake suggests that the SKL-Y-1 model will have 2 cores and a thermal design power (TDP) of 4 W.  Let's assume the TDP represents the actual power consumption for our mining application, and furthermore let's neglect the power consumption of all other components of our machine (memory, power supply, etc).  There isn't any information given on clock speeds, but Intel's current Core M processors have a base clock speed of up to 1.2 GHz, with "turbo" up to 2.9 GHz.  Let's suppose this new Skylake device could run at 3 GHz sustained.

So our overall hash rate is

 3x10^9 clocks/sec / 64 clocks/hash * 2 cores =  93.75 MHash/sec

With a power consumption of 4 W, this gives an efficiency of 23.4 MHash/J.

By comparison, according to bitcoin.it's Mining hardware comparison, current ASIC miners are able to produce 1000-2000 MHash/J.

Conclusion:

  Even under extremely optimistic assumptions about the mining performance of the Skylake processors, modern ASIC devices are still 40-80 times more efficient.


Multiple input/output transactions using golang btcd

There might not be an easy answer, but the developper documentation is probably a first stop (https://bitcoin.org/en/developer-examples#complex-raw-transaction). Also I used regularily a block explorer (e.g. blockchain.info) to display the transaction and also its "raw" format. This allows to see the tx details in it's JSON format. Also the book from Andreas helped alot (Mastering Bitcoin). And finally there is also this forum here (the search function is good), and bitcointalk.org. Oh, then there is the wiki as well: https://en.bitcoin.it/wiki/Protocol_documentation#tx.

  For the inputs, is it as simple as taking all the input transactions
  into little-endian, noting the correct number in inputs, and going
  from there?

No, I don't think so. There is no such thing as simple :-)
You are on the right path, additionally when assembling a raw, unsigned transaction, and you have to deal with field lengths, and with "var_int", which are explained in developper docs. Here is a sample tx, so you get an idea:

VERSION                                 01000000
TX_IN COUNT [var_int]:                  hex=03, decimal=3
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])     94FAE0AC28792796063F23F4A4BA4F977A9599D1579C5AAE7CE6DDA4F8A6B1BB
  TX_IN[0] OutPoint index (uint32_t)    hex=14040000, reversed=00000414, decimal=1044
  TX_IN[0] Script Length (var_int)      hex=19, decimal=25
  TX_IN[0] Script Sig (uchar[])         76A914A438060482FCD835754EA4518C70CC2085AF48FA88AC
  TX_IN[0] Sequence (uint32_t)          FFFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash (char[32])     A3E719B12275357B15FC5DECD9088A0964FE860D49F026F2152E71F681AC3FA4
  TX_IN[1] OutPoint index (uint32_t)    hex=31040000, reversed=00000431, decimal=1073
  TX_IN[1] Script Length (var_int)      hex=19, decimal=25
  TX_IN[1] Script Sig (uchar[])         76A914A438060482FCD835754EA4518C70CC2085AF48FA88AC
  TX_IN[1] Sequence (uint32_t)          FFFFFFFF
 TX_IN[2]
  TX_IN[2] OutPoint hash (char[32])     874CD4C4E1683C43A98A9DAA0926BEA37C10616F165AC35481E8181BFD449C65
  TX_IN[2] OutPoint index (uint32_t)    hex=E0010000, reversed=000001E0, decimal=480
  TX_IN[2] Script Length (var_int)      hex=19, decimal=25
  TX_IN[2] Script Sig (uchar[])         76A914A438060482FCD835754EA4518C70CC2085AF48FA88AC
  TX_IN[2] Sequence (uint32_t)          FFFFFFFF

TX_OUT COUNT                            hex=01, decimal=1
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)            hex=8038010000000000, reversed_hex=0000000000013880, dec=80000, bitcoin=0.00080000
  TX_OUT[0] PK_Script Length (var_int)  hex=19, dec=25
  TX_OUT[0] pk_script (uchar[])         76A914C2DF275D78E506E17691FD6F0C63C43D15C897FC88AC
LOCK_TIME                               00000000

  For outputs, do you just have an individual block of to satoshiBytes
  to scriptPubKey?

It is similiar to the example above, just don't have one at hand. But the majority of tx have a spend-to address, and a return address, so you might look a tx up in the block explorer...
Happy coding ! :-)


From Satoshi's paper (my emphasis):

  By convention, the first transaction in a block is a special
  transaction that starts a new coin owned by the creator of the block.
  This adds an incentive for nodes to support the network, and provides
  a way to initially distribute coins into circulation, since there is
  no central authority to issue them. The steady addition of a constant
  of amount of new coins is analogous to gold miners expending resources
  to add gold to circulation.  In our case, it is CPU time and
  electricity that is expended.

I don't know of any other examples where the word has been used in a similar manner.


Asterisk is the currency symbol for XLM, like $ or ฿.


Will DHS eventually stop wire transfers to/from Mt Gox?

Take a look at beta bitinstant at https://new.bitinstant.com/ No longer option for cash to mtgox.  Could be possible indicator.


Will Bitcoin Transaction Evicted From Mempool Disappear From Blockchain Explorer?

First of all, there is no "the Bitcoin mempool". Each node has its own mempool, so if the transaction is evicted from one node's mempool, there is no guarantee that it has been evicted from other node's mempools.

If most nodes have evicted a transaction, it still may appear on a blockchain explorer because they may have other configuration settings which has them have a larger mempool and hold onto transactions for longer. Generally blockchain explorers have less restrictive mempool configurations than most nodes, so if a transaction disappears from multiple block explorer's mempools, then it is likely that most nodes on the network have evicted the transaction.


I think your scenario would work if you have a way of broadcasting the ELB address (or preferably CNAME) to known entities across a network. For instance we know from a previous answer "Several host names (such as dnsseed.bluematt.me) are maintained that resolve to a list of IP addresses known to be running nodes." (bitcoin.stackexchange.com/a/3537/44818).


Does a Bitcoin qr code become invalid after 1 Year?

Generally no. A Bitcoin QR code encodes a Bitcoin address. These addresses are valid forever - in the sense that valid Bitcoin transactions can be created which pay to those addresses. So long as someone still knows the original private key (or master private key) for the address, any money sent using that QR code in 5 10 or 100 years time, can still be used.


When or how does one becomes a part of Bitcoin P2P network

When you sign up for a wallet or exchange site, you are not becoming a node on the network.  You are using a site that already runs several nodes on the network, and you are trusting them to send and receive transactions for you.

To actually join the network, you need to run your own node.  This can be a full node or an SPV node, but the point is you are running it yourself.  Otherwise, you are using a 3rd party to connect to the bitcoin network on your behalf.


How can I ensure that bitcoind does not use unspent outputs for a given address?

You can use lockunspent to lock (in-memory only) unspent inputs created by transactions whose at least one output was pointing to your "special address".


How can I generate the qrcode client-side that would be compatible with the Ardor Wallet qrcode

The Ardor wallet uses the NRS.generateQRCode() function from nrs.server.js to generate a QR code based on string data into a target div. Both the data and the div reference are provided as parameters.
This function relies on the qrcode.js library from the 3rdparty folder.


Is it possible to make PoW ASIC-resistant through dynamically generated hash chains?

There cannot be such a thing as an “ASIC-resistant” algorithm. ASICs are designed specifically to implement an algorithm and will always be faster than any CPU.

On the other hand, it might not even be a good idea to have ASIC resistance, because ironically, the ASICs would be the ones optimized for this and the general-purpose computers would be left behind, while also being way worse for energy consumption (something which seems to bother many people).

Source: https://download.wpsoftware.net/bitcoin/asic-faq.pdf


Cudaminer On Mac OS X installation error: "malloc.h: No such file or directory"

I get the same error using OS X 10.9 MBPR.

Even though I followed http://atomton.roon.io/compiling-cudaminer-on-os-x-10-9 exactly.

UPDATE: PROBLEM SOLVED.

by changing
include malloc.h
to
include malloc/malloc.h

in both scrypt-jane.cpp
and sha3.cpp


I figured this out a while ago. Couple of weeks after I got hacked I noticed an unknown process in the task manager. After googling the name of the file that was linked to that process (I don't remember the file's name) I found out it was a trojan horse. Afterwards I deleted it, changed my passwords, and checked out from time to time for unfamiliar processes.
I suspect that whoever did this, connected to my accounts through my session, thus bypassing my two factor authentication both on my Cryptsy account and my Gmail.
Update:
After some digging I found an infected file named Bitcoin.Trading.Botv4.6.exe. This is probably what caused the Trojan to appear in some random temp folder. I don't remember where I downloaded this, or when I ran this, and I'm pretty sure that it wasn't identified as a threat back when I first ran it. I included a link to the scan results here.


How much on-chain activity is to and from exchanges?

Blockchain.com show charts of "The total USD value of trading volume on major bitcoin exchanges."

Doubtless there are other publishers of equivalent data.


You can find n by consulting a discrete log oracle, such as myself. N is 5. You're welcome.


Why is the obscured commitment number necessary in lightning commitment TX's?

Looking at the c-lightning code I find this call:

    txs[0] = commit_tx(ctx, &channel->funding_txid,
               channel->funding_txout,
               channel->funding_msat / 1000,
               channel->funder,
               channel->config[!side].to_self_delay,
               &keyset,
               channel->view[side].feerate_per_kw,
               channel->config[side].dust_limit_satoshis,
               channel->view[side].owed_msat[side],
               channel->view[side].owed_msat[!side],
               committed,
               htlcmap,
               commitment_number ^ channel->commitment_number_obscurer,
               side);

in particular the following line:

commitment_number ^ channel->commitment_number_obscurer

Tracing down the commitment_number variable this suggests to me that it is really an integer. If you see how often in the code it has to validated that two commitment transactions are directly succeeding each other it makes sense to have an unobscured integer instead of a txid. Consider For example this code block:

    /* FIXME: Document this requirement in BOLT 2! */
    /* We can't send two commits in a row. */
    if (peer->revocations_received != peer->next_index[REMOTE] - 1) {
        assert(peer->revocations_received
               == peer->next_index[REMOTE] - 2);
        peer->commit_timer_attempts++;

It is obscured later since the information how many commitment tx existed should not be public. It is as far as I understand obscured with an OTP via XOR. The OTP is the one you mentioned above. The idea is to have an integer that can be used but obscure it when being sent to the blockchain. I did not find a position in the code where the obscured value is taken and processed to a clean value however.

I hope that helps (:


Does the synced blockchain always grow in size?

The Bitcoin.org client v0.7 and lower will continuously increase in size about once every ten minutes, on average.

Blockchain.info provides a chart showing the size of the data (actual disk consumption will be slightly larger even.)

The Bitcoin.org client v0.8, being developed now, dramatically changes how it stores and accesses data that will reduce the amount of disk storage space to some degree but also will provide a dramatic increase in performance.


The difficulty actually does not continually increase. It has continued to increase recently because hashing power has continued to increase, causing blocks to be found quicker. Difficulty is calculated by taking into account how long it has taken for the network to create 2016ª blocks and adjusting the difficulty accordingly.

Here's some messing around in a Ruby interpreter to show it:

#two weeks, expressed in seconds
twoweeks = 60 * 60 * 24 * 7 * 2
# => 1209600
#the current difficulty as of the time of this posting
diff = 7988698.97
# => 7988698.97
#the difficulty if it took only a week to generate the past 2016 blocks
(diff * twoweeks) / (twoweeks / 2)
# => 15977397.94
#the difficulty if it took four weeks to generate the past 2016 blocks
(diff * twoweeks) / (twoweeks * 2)
# => 3994349.485

A pair of maximums keep the difficulty change from being too abrupt. It can never more than quadruple (four times, 400% of the previous difficulty) or more than quarter (one quarter, 25% of the previous difficulty).

ª A bug makes it be actually 2015 in the reference client, but that may be fixed at some point in the future.


Speaking as one of developers on MultiBit, it is not currently implemented at the time of writing (Dec 2011) but there are serious development efforts to consolidate the wallet file format to suit all major Bitcoin clients.

Expect to see this functionality in Q1 2012.


Is it possible to mine with both (2) GPUs in headless mode?

I have tried the bitminter client for mining and it seems that both of my gpus are used.

You can try downloading it from here


Install

Download NSSM
Comment out #daemon=1 from bitcoin.conf with comment #incompatible with windows service
Shut down bitcoin-qt, bitcoind, bitcoin-cli to eliminate any confusion
nssm install BitcoinCore "C:\Program Files\Bitcoin\daemon\bitcoind.exe" -datadir=C:\Documents\Data\Bitcoin (use your own path of course)
nssm set BitcoinCore DisplayName Bitcoin Core
nssm set BitcoinCore Description Bitcoin node with a JSON-RPC server

Test

You should be able to see 8333 connections in netstat
You will see bitcoind in your task list under Details
If you go to Service(s), it will take you to this service.
bitcoin-qt still works even in testnet mode
bitcoin-cli still works even in -testnet
Your app still works even in testnet mode

Running mainnet and Testnet both
Repeat the steps for install, but on step 4, use
nssm install BitcoinCoreTestnet "C:\Program Files\Bitcoin\daemon\bitcoind.exe" -testnet=1 -datadir=C:\Documents\Data\Bitcoin

You will then be able to take requests for mainnet on port 8332 and testnet on port 18332


The pool will typically ignore invalid shares. They should have no effect on shares that are actually accepted.

Some pools might consider excessive submission of invalid shares abusive, especially if done at high rates. The point of an increased difficulty is precisely to avoid this. So you might find you get suspended or disconnected. But most pools would probably just tolerate it unless it actually caused them an operational issue.


How to know whether my transaction is fraudlent after one confirmation?

You cannot undo a confirmed transaction trivially. That is one of the key benefits of a network like Bitcoin.

If your tx has only 1 confirmation, you might yet be able to drop it by mining two blocks on the parent of the block that contains tx_1. However, this requires you to have enough hashpower to be able to do so before someone extends the chain building on the block containing tx_1, which is non-trivial. Additionally, even if you succeed in this, there is still a chance that someone might mine on the block you dropped and turn that into the longer chain again.

Usually, blocks which have been confirmed 6 times are considered irreversible. Practically, unless you have access to a large amount of hashpower, even 1 confirmation is effectively irreversible on the bitcoin chain (although orphan blocks do occasionally happen)


I read about this in https://www.forbes.com/sites/stevenehrlich/2021/04/13/janet-yellen-bitcoin-and-crypto-fearmongers-get-pushback-from-former-cia-director/
I have categorized privacy and anonymity involved in Bitcoin transactions as (based on few cases that I have studied):

Network layer
Blockchain
External

Network: Use of full node, Tor, i2p, etc.
Blockchain: Information available publicly for every transaction like amount, type of transaction etc.
External: Lot of users share information about their bitcoin addresses or transactions on social media. Example: You can search for "blockchain.com/btc/tx" on Telegago to check lot of transactions shared in different telegram groups or channels.

In terms of it being digital this makes sense, and of course the public ledger would showcase all transactions, but aren’t the identities of those transacting hidden cryptographically?

It is mentioned in the paper: “[It] is easier for law enforcement to
trace illicit activity using Bitcoin than it is
to trace cross-border illegal activity using
traditional banking transactions, and far
easier than cash transactions.”
Yes, its easier to trace digital payments compared to cash transactions. One of the reasons governments are moving towards to cashless economy. Demonetization that happened in India few years back and usage of digital payments since then is a great example. Although I am not sure about banking transactions because it varies from one bank to another and different places in the world. There are lot of other things used by criminals which exist since years but I consider them to be off-topic here so will not go in to details.
Bitcoin protocol involves no KYC. In every country, the only way to prove your identity or who you really are is done using documents issued by governments like Passport. None of these things or biometrics are stored on Bitcoin blockchain. So every transaction is publicly visible but users can avoid links of any transaction with real identity by following few best practices mentioned in a link below.

If Cryptocurrency offers anonymity, why is it considered by forensic professionals to be the best currency for fighting illicit transactions?

I am assuming its because of their confidence in the tools they find helpful in tracing Bitcoin transactions. Also we cannot blame the privacy or anonymity of Bitcoin transactions in every case because most of the cases involve things like address reuse, using KYC exchanges, information shared on social media etc.
Michael Morell (Former CIA Director) has mentioned few things that support my arguments about their confidence in the use of tools used for tracking:
Blockchain analysis is a highly effective crime fighting and intelligence gathering tool.
But that is not all. Perhaps even more interesting to Morell was how analytic firms such as Chainalysis, CipherTrace, and Elliptic can employ forensic and artificial intelligence tools to find illicit actors and activity on blockchains. In fact, he said that he was “literally blown away by how they find illicit activity...this is great intelligence work.”
I don't trust everything shared by firms like Chainalysis and artificial intelligence is helpful but has its own issues when used for analyzing Bitcoin transactions. I have mentioned the details of an independent investigation related to Mt. Gox case: https://bitcoin.stackexchange.com/a/101959/. You will find the investigator had to assume lot of things for tracing Bitcoin transactions.
Will share few charts that look interesting although as I mentioned above firms like Chainalysis have incentives in promoting their business and mislead people about privacy and anonymity in Bitcoin:

You can check other details here: https://go.chainalysis.com/rs/503-FAP-074/images/Chainalysis-Crypto-Crime-2021.pdf
Lastly, how do we improve privacy and anonymity involved in Bitcoin transactions? Quoting sipa from one of the Reddit post:
Nothing is "sufficient" for privacy. It's a goal to work towards, but it is so multi-faceted that no single piece of technology can "solve" privacy.
 https://www.reddit.com/r/Bitcoin/comments/e65vdf/could_bitcoins_privacy_benefit_from_litecoins_eb/f9oxfyk/
I have mentioned the difference between privacy and anonymity, best practices for Bitcoin transactions and few other things in this answer: https://bitcoin.stackexchange.com/a/103255/


Does Electrum require the Satoshi client?

No, Electrum doesn't require Bitcoin-Qt to be installed on your computer. Electrum and BitcoinJ aren't full clients, though, so they do rely on Bitcoin-Qt at some level -- Electrum through the Stratum network and BitcoinJ through the Bitcoin network's SPV mode.


Generating a segwit (bc1) address from a brain wallet?

Here's an example with bitcoinjs-lib:

let bitcoin = require('bitcoinjs-lib');
let assert = require('assert')
let bigi = require('bigi')

let NETWORK = bitcoin.networks.bitcoin;
let brainwallet = "This is my brain wallet and it is less secure than a CSPRNG source";
let hash = bitcoin.crypto.sha256(brainwallet);
let d = bigi.fromBuffer(hash);
let nkeyp = new bitcoin.ECPair(d);
let wif = nkeyp.toWIF();
let pubKey = nkeyp.getPublicKeyBuffer();
let scriptPubKey = bitcoin.script.witnessPubKeyHash.output.encode(bitcoin.crypto.hash160(pubKey))
let address = bitcoin.address.fromOutputScript(scriptPubKey);
console.log(address);
console.log(wif);


How do I iterate through the entire Blockchain using RPC?

Your plan is correct (use getrawtransaction <hash> 1 to get JSON instead of HEX :D) but the RPC becomes slow > 60% of the blockchain because there's between 500 and 2k transactions to go through.
Make sure txindex=1 is in your config so it has the rawTX data.

As suggested by George parsing the raw files stored will make a very significant difference, to save you a lot of work;
this project (by bitpay) already does a that nicely:
https://github.com/bitpay/insight-api


What happens if I lose Bitcoin Investment, is there Bitcoin insurance?

So far as I am aware, no currency, whether fiat or cryptocurrency offers intrinsic insurance against accidental loss of cash.
For example is a shopkeeper takes dollar bills from their cash register and drops it unnoticed in the street on the way to the bank, they will not be covered for that loss by the US treasury. The shopkeeper will only be covered by any relevant insurance whose cover includes that kind of loss.
Bitcoin insurance exists in the same way that dollar insurance exists for cash.
Bitcoin was designed to do away with trusted third parties such as banks therefore there is no need for government organised recompense for bank failure.


How does Peercoin (or other PoS) prevent timestamp forging effecting hash attempts or random minting?

The general problems you are describing are inherent flaws in PoS, but you've caught onto some of the basic principles that are going to impact the security and integrity of the cryptosystem.

  Anyway, even if we can't roll back in time, could we edit the program to try as many hashes as possible every second. For example, suppose we try 100 times to hash instead of once, for a given second, we then broadcast the block.

This is known as stake grinding.

The selection of the next signer in the block chain is almost always (this varies by implementation) directly or indirectly deterministic based on the previous block information. As there is nothing inherently preventing a person from resigning previous blocks as much as they like, they can continue until the head of the chain also assigns them to be the next signer of a block as well. Under this attack either one person gains a vastly inflated amount of power over the chain, or if everybody is attempting to stake grind it breaks down to a particularly inefficient proof of work system with badly described properties.

Proof of Stake altcoins generally attempt to solve this by making the signer selection RNG seed come from earlier in the chain, say a thousand blocks prior to the head, with the idea that it is impossible for someone to influence the outcome from that far back in time.

  I guess there exists a "start time" on the block chain we can't roll the clock before because transactions with timestamps already exist on the chain. But could we roll back say just a few minutes? Could this gain us anything?

This is known as costless simulation.

The system again falls to the simple fact that there is nothing inherently hard about resigning blocks. Given some coins at the start of the block chain (owned, stolen, "empty" wallets purchased), in a proof of stake system an attacker can simply rebuild the entire chain to the present day with themselves as the only participant. Given the option of two chains (in this case, the attacking and main chain), a client has no way of knowing which if either they should be trusting as real.

Proof of Stake altcoins often attempt to solve this by having centralized "checkpoints" which prevent the chain from deviating, though one could argue against this system being decentralized at all. Others simply have nodes in the network refuse to reorganize to other chains after a certain amount of time, which doesn't protect new users joining the network and being presented with false chains. Ethereum PoS will attempt a "phone a friend" system, where users are prompted to contact other network participants out of band and manually confirm that they are on the same main block chain.

Section 6.4 of A Treatise on Altcoins covers these topics in a little more depth.


How often is a block mined on the bitcoin testnet?

Blocks on testnet3 are intermittent; sometimes there's hundreds of blocks a second, massive reorganisations that strike out tens of thousands of blocks, or no blocks for many hours. This is largely due its zero value and the difficulty adjustment rules that don't deal well with changes in hash rate. Generally no software is tested here other than for public demonstrations as a result.

For more reliable testing the regtest mode exists in Bitcoin Core which allows you to instantly create blocks on demand in your own isolated testnet with as many peers as desirable.


Will nodes configured with a larger-than-default mempool automatically retransmit transactions that have been dropped from the default mempool?

So far, Bitcoin Core rebroadcasting is a wallet-level responsibility. Transactions that aren't relevant to any of the Bitcoin Core's internal wallet are not rebroadcast at all.
There is work to change that: https://github.com/bitcoin/bitcoin/pull/21061. This makes sense, as right now, observing a rebroadcast is a very clear sign that the transaction belongs to the wallet, which is a privacy leak.
So I think in short the answer is: yes, it makes sense, but so far it hasn't been done.


Is there a way to provide the walletpassphrase to bitcoind without exposing it on the cmdline?

Anything you can do from the command line you can also do from the JSON API which means that the same unlock command could be sent from within code just as easily. To my knowledge there is no pre-built utility capable of this, but the API is simple enough that I can't imagine it being terribly difficult to actually build such a tool.

Edit: It was much easier than expected to do this in Python. Assuming you have Python's JSON-RPC module installed just use this code:

from jsonrpc import ServiceProxy
from getpass import getpass
access = ServiceProxy("http://127.0.0.1:8332")
pwd = getpass("Enter wallet passphrase: ")
access.walletpassphrase(pwd, 60)

Similarly you could call access.walletlock() to lock the wallet on demand and walletpassphrasechange(old, new) to change the passphrase without ever having it see the command line.

Edit 2: I also submitted an issue to the devs on github on your behalf.

Edit 3: A pull request containing my python scripts has been accepted. Downloading the bitcoin source from github now includes scripts for this purpose in contrib/wallettools

Edit 4: A new bug report was filed to request that the builtin command behaves properly.


I STORED 0.0154 BTC IN MY BLOCKCHAIN WALLET FOR MINING PURPOSE

Mining bitcoin does not require putting bitcoin into a wallet you own.

Asking people to link their wallets to a miner is a favourite trick of conmen / scammers.

  IN THE NEXT MORNING I FOUND MY BALANCE TO BE 000 , WHAT DOES THAT MEAN?

If someone else knows the password to your online wallet, they can extract from it the "private key" which gives control over any bitcoin already sent to addresses in that wallet as well as any future amounts sent to addresses in that wallet (even after you change wallet passwords).

It is likely you are the victim of a conman and your money has been stolen.

Related questions with useful answers:

BTC Stolen from Blockchain

  A guy ... told me that I can mine for bitcoin ... Within half an hour my wallet was empty.

Bitcoin Mining as a Newbie (link wallet to another person's miner)
I've been asked to share wallet credentials to participate in mining. Is that a scam?
I NEED YOUR HELP URGENTLY Bitcoins


Future-proofing a deflationary currency from future counterfeiting

There are a few things one needs to consider:

Bitcoin software is bound to change. It will be adapted to new systems, hardware, and so forth. Expecting a program from now to work 100 years from now is probably not going to happen.
Bitcoin protocol probably will change, but the change will be less drastic. For example, block size might get changed. If a protocol changes, it makes software that uses old protocol not able to properly communicate with the network.
The last part that needs to be addressed, is whether or not the way bitcoins are "stored" will change. At the moment, everything is handled using secp256k1 ECDSA algorithm. In order to spend bitcoins, one needs to sign a transaction with their private key. The exact specific of what such a transaction might look like is likely to change, but the algorithm itself is very unlikely to change unless some serious threat appears for Bitcoin. At the moment, quantum computers are a thing that might or might not brake that algorithm in the future. If that was to happen, the algorithm would be changed.

In order to be able to access one's bitcoins 100 years from now, one would need to get their hands on a piece of software from that time (pretty easy), that works with the protocol at that time (very easy), and the Bitcoin protocol must still accept ECDSA signatures or at least private keys (unknown).

Provided secp256k1 is still secure in the future, your coins will be yours to claim (unless someone adds an unlikely exception of "coins older than X years cannot be spent").


Where does "Included in Block" value comes from?

I was wondering, how is this attribute populated?

The site uses an index that simply remembers this information. If a block B is seen that contains a transaction T, an entry is stored in the database that signifies "transaction T is in block B".

by looking at transaction inside of your UTXO, check in which block transaction was included (and then I found this attribute)

The UTXO set does not contain this information, nor can it be efficiently requested from arbitrary nodes in the network.


This transaction (e8c5...) will never confirm because its inputs have already been spent by transaction 93cc4fe50e6069dccb827f56636bb4cd20f9865dd4d7e3b7946bbbca97576e80, which currently has 9 confirmations.

There isn't any inherent need to cancel transaction e8c5; the network is never going to consider it valid.  You might want to remove it from your wallet client software in order to avoid having it display an incorrect balance or other confusion.  How to do that will depend on what software you are using.


What happens to the transactions included in the forks?

On nodes that had accepted block100: when they disconnect it to reorg they will remember the transactions in it and attempt to reinsert into the mempool any that fell out once they finish the reorg. If they're still valid, they'll be added and queued for mining in a future block.

On nodes that initially accepted block110: the transactions that were still valid after accepting the block will remain in the mempool queued for mining in a future block.

Transactions which were invalidated by other transactions included in block110 are forgotten by nodes.


why is the double spending problem is a problem in cryptocurrency?

With physical dollars, double spending is not an issue.  You either physically possess the dollar or you don't.  Once you give the dollar to someone else, it can't magically reappear in your wallet.

Non-physical dollars, such as a bank account, solve this problem by centralized trust.  Your bank is trusted to decrease the value in your account when you transfer money from it, and increase the value when you transfer money to it.  These transactions are audited against the records of the institutions the bank interacts with (other banks and financial institutions), which helps ensure the accuracy, but at the end of the day it is trust in your bank that prevents double spending.

Cryptocurrencies are digital, and digital assets can be copied perfectly.  This had always been a problem for creating a digital currency.  Let's pretend that a certain image was used as a digital currency.  What prevents you from copying this image millions of times, and double spending it?  This is the problem Bitcoin solves by using a blockchain.  It is able to verify that a digital asset is only transferred once, and do so without a centralized authority like a bank.  Without trusting anyone in particular, you can be sure that a payment you received was not (and never will be) received by someone else as well.  Just like being handed a physical dollar.


How happens the serealization the data in the file blkxxxx.dat in the bitcoin

You are being confused three ways.

First, you need to be careful that some of your numbers in decimal, others are in hexadecimal: 77 decimal -> 4d hexadecimal (so: 77d -> 0x4d)

Second, you need to be careful that most numbers are stored in little endian notation, so 0x00000001 -> 0x01000000. Theymos' discussion why little endian is used.

Third, you have mixed up numbers from the Genesis Block and those from block 125552:

The Genesis block nonce 2083236893d converts to 0x7c2bac1d as hexadecimal not 0x42a14695.

0x42a14695 is the nonce mentioned at https://en.bitcoin.it/wiki/Block_hashing_algorithm for Block 125552, not for the Genesis block.

Similarly, Nbits 486604799d is for the Genesis block, 0xf2b9441a is for block 125552. Timestamp 1231469665d is for the Genesis block, 0xc7f5d74d is for block 125552.


The code comments that serve as the library's documentation explain what it does:

/** Opaque data structure that holds context information (precomputed tables etc.).
 *
 *  The purpose of context structures is to cache large precomputed data tables
 *  that are expensive to construct, and also to maintain the randomization data
 *  for blinding.
 *
 *  Do not create a new context object for each operation, as construction is
 *  far slower than all other API calls (~100 times slower than an ECDSA
 *  verification).
 *
 *  A constructed context can safely be used from multiple threads
 *  simultaneously, but API call that take a non-const pointer to a context
 *  need exclusive access to it. In particular this is the case for
 *  secp256k1_context_destroy and secp256k1_context_randomize.
 *
 *  Regarding randomization, either do it once at creation time (in which case
 *  you do not need any locking for the other calls), or use a read-write lock.
 */
typedef struct secp256k1_context_struct secp256k1_context;

libsecp256k1 is not an object oriented library nor is it able to store various useful states. So the context object allows the useful states to be kept.

You should generally only create one because the stuff it generates and stores is relatively expensive to compute. To use the context, just create a new context that supports the operations you want to do using the secp256k1_context_create function. You pass in the bitwise OR'ing of the SECP256K1_CONTEXT_VERIFY, SECP256K1_CONTEXT_SIGN, SECP256K1_CONTEXT_NONE flags which represent the type of things you want to do.

E.g. if you wanted to create a context that will be used in signing functions, you would create a context with:

secp256k1_context* secp256k1_context_create(SECP256K1_CONTEXT_SIGN);

If you wanted one that can be used with both signing and verifying, you do:

secp256k1_context* secp256k1_context_create(SECP256K1_CONTEXT_SIGN | SECP256K1_CONTEXT_VERIFY);

The resulting context you just use as the context argument for any function that needs one.


Besides your course, there's Khan Academy's, Stanford's cryptography course, and a rather superficial course on lynda, amongst more scattered material.


RPC port is 8332 by default for mainnet, 8333 is the Bitcoin network protocol port.

Also, be sure to set the rpcallowip variable if you are connecting to the node from another host on the network (non-localhost connections are blocked by default).


No, you don't need to do anything.

  If so then in that Case I assume that the accurate balance in the Cold Wallet does not need to be reflected as it is only used for spending?

Correct. Without a means to gain knowledge about received money, the cold storage wallet can't update its balance. But it holds the private keys required to spend the money it received. The watch-only wallet can be used to check the balance without it having the ability to spend any money.


Starting from basics, each input spends a previous output:

To spend the output, the input has to include a reference to it (called an outpoint).  This includes the TXID that included the output as well as the sequence number of that output in the transaction (called a vout for output vector).

In order for Alice to pay Bob in a pay-to-public-key-hash (P2PKH) output, Bob needs to create a private key (which he keeps secret), derive a public key, hash that public key (encoding it as a Bitcoin address), and then give that hash to Alice.  Alice uses that hash in a P2PKH output in TX1.

When Bob wants to later spend that output from TX1 (using it as an input), his computer gets the hash (address) from the TX1 output, finds the corresponding public key, inserts that public key into the signature script, then finds the corresponding private key in its secure database, and uses that key to create an ECDSA signature which it also adds to the signature script.

So only one keypair is used per output, although the same keypair may be used in multiple outputs.  (This is called key reuse, and it's discouraged to improve privacy and, possibly, security.)
(The images above are from the Bitcoin.org Developer Guide transactions section, which is under the MIT license.)


Multibit HD shows confirmed transactions as unconfirmed

Multibit HD is end of life software so you should migrate to Electrum. The MultibitHD developers themselves advised users to do that. Here's a detailed guide.


How could an LN node acquire inbound liquidity? Is there any systemic risk?

Dual funded channels are theoretically easy but there is a little bit of implementation overhead. Also they are not fully spect out yet in the BOLT standard which is the reason why they are not implemented yet. They will be part of the next update to BOLT 1.1 and people are working on the specification.

While studying the Lightning Network white paper last year I discovered a potential 51% attack vector which I described on the Mailinglist. The attack can steel all the capacity that is in all your channels. With dual funded channels you could in fact increase the capacity that is attached to you. However the described 51% attack is rather unlikely to happen and in particular would yield many other problems.


how is blockchain data stored and accessed?

Blockchain: Chain of blocks
+++++----------++++---------++++++---------+++++++
Who creates the blocks? Miners
Who validates, saves and relay these blocks? Full nodes
https://bitcoin.stackexchange.com/a/103172/

Different full node implementations for Bitcoin: Core, btcd, bcoin, gocoin, libbitcoin, knots, etc.
Database used by Bitcoin Core: Bitcoin Core stores the transaction-journal in groups of consecutive blocks in a series of large files whose format I believe closely matches the form used in the Bitcoin network protocols. But there is no prohibition on other software products doing something quite different.
https://bitcoin.stackexchange.com/a/98830/
Berkeley DB and SQLite are used for wallets


How many different formats can a public address take?

I believe that the earlier format that you are referring to is the Hash160 which is formed by taking the sha256 of the public key followed by taking the ripemd160 of the result:

Hash160 = ripemd160(sha256(pubkey))

Further, what we usually refer to as a Bitcoin address is formed by first concatenating the Hash160 with four checksum bytes (to make it extremely unlikely that you can type the wrong address into a bitcoin client by accident). Then, a network identifier (0x00 for main network) is prepended and the string is base58 encoded:

address = base58(0x00 + Hash160 + checksum)

As you can see these two formats can easily be converted from one to the other. In addition the public key can be encoded either compressed or uncompressed. This results in two different addresses. However, since you can obtain the public key from neither the Hash160 nor the base58 address it is not possible to convert an address of an uncompressed public key to the address corresponding to the compressed public key, and vice versa.


Can someone explain double spending to me?

No you cannot. When you try to send a transaction to the chain which is not allowed by the chain (so sending more coins then you own) results in a invalid transaction. The case now is that your program didn't process your recent transactions, and therefor thinks that there are more bitcoin in your wallet then there really are. Otherwise it would be far to easy to doublespend: just reinstall Bitcoin Core and have a wallet which held a lot of BTC prior a specific date. If you are interested in reading more about doublespending (which I think you are not, just wanted to know if you were possible right now) you can read this.


Can I use Bitcoin mining as a data furnace to heat my home?

Yes, you can use a Bitcoin mining rig to heat your home.

Whether or not it's worth doing depends on a number of things, such as:

Whether you have a heat pump, or would otherwise install a heat pump (they generally give you 3kW of heat for around 1kW of electricity)
Whether of not you have other heating that is more cost effective than electric heating (eg a wood or gas fire)
Whether it's convenient to have a mining rig in the location you want heated (you lose efficiency if your heat is produce away from where you want it)
The current exchange rate of Bitcoins (and the difficulty of mining them), and how those values change over time for at least the payback period of the mining hardware
The price of electricity
The noise produced by a mining rig. They tend to be quite noisy, so it may be a disturbance to leave it running overnight
Your technical ability to maintain the equipment, and your time available to do so. If it has a problem and you don't have time to fix it, you stop earning mining income.

There's no guarantee that mining earnings will pay for the electricity to run them, let alone pay for the cost of the equipment and the labour incurred maintaining it - this is dependent on the demand for Bitcoins, and your costs. There's always a risk that the exchange rate will drop to the point where it's not worth mining at all, or that new technology (eg ASICs) will make your hardware obsolete before it's paid for itself.

Any web-based profitability calculators that exist won't necessarily take into account all the factors above, and none can predict the Bitcoin exchange rate, so their usefulness will be minimal. I recommend just creating a spreadsheet to do the calculations. To include the value of the heat output in your calculations, consider what you would need to otherwise spend to obtain the same heat output, and include that figure as profit on top of the mining profit (but also of course account for the cost of electricity to run the rig).

To predict the electricity usage of a particular setup, see this hardware comparison - a carefully built rig can run 4 graphics cards which might output 600-800W (or more) of heat. Using a desk fan (or similar) to keep strong air flow on the rig should reduce the potential of a convective flow of air taking the rig's heat straight up to the ceiling, where it won't be felt in cold weather.


Is it possible for a decentralized currency to have untraceable transactions?

You are quite right that there are some drawbacks to reusing a bitcoin address, while at the same time it can be inconvenient to generate a new address each time.

I think you'll find its not possible to make an untraceable payment system where the money supply is limited. If money creation is controlled (as with bitcoin), nodes need a way to trace the money back to a valid origin.

As for the limitations of bitcoin, read on.

You might be interested in BIP 21 (Bitcoin Improvement Proposal 21), which is an official URI extension which bitcoin clients or wallets can use to make payments easier. Basically a seller can present a bitcoin URI (i.e. a link) to the buyer, and if the buyer's bitcoin client is compatible, the bitcoin client shows a payment screen saying e.g., "Would you like to send Bob 20 bitcoins?". What you should note is the seller can put any bitcoin address in the URI, meaning if most bitcoin clients + sellers supported this scheme, many transactions could easily use one-off bitcoin addresses, which helps achieve the privacy you're after.

Note there is still the problem that in can be tricky to send bitcoins to e.g. a friend, and that like you said, being able to 'discover' someones bitcoin address by using e.g. their email address would be handy. I have a side project Bitcoin Payment Service which attempts to solve that problem. Basically its an open-source web app that allows anyone to initiate a bitcoin payment to the web site's owner. You can check out a demo of BPS.


The code is effectively just a long random string.  When you create a redeemable code, a random string is selected, entered into the database at the exchange and associated with a currency and an amount.  That string is your redeemable code.  The string is long enough to make it very unlikely that anyone would be able to guess it in a reasonable length of time.

The first person to attempt to redeem the code gets the amount credited to their account on the exchange, which causes the database entry on the exchange for that code to be marked as having been redeemed.

The way to tell whether a code is valid is to try redeeming it.  If it works, you're the first to try it.  If not, you're either not the first to try using it, or it was never a valid code to start with.

The exchange should prevent "double-spending" by making sure that the "look up whether code is spent; credit account; make code as spent" sequence is an atomic operation.  We don't want two users both running through that same sequence at the same time, where both pass the "look up whether code is spent" check, then both accounts get credited, etc.


Transaction fee of 8.44 mBTC for 1.22 mBTC?

This is a process known as consolidation - If your wallet has several small inputs, many wallets will often try to combine them into a single change input during regular transactions, especially ones made with a low sat/byte feerate. This allows you to spend the coins in a smaller transaction during possibly high traffic times, when the feerate may be much higher.

These days, many wallets only perform such consolidation if there are many outputs to a single address, as combining outputs from multiple addresses unnecessarily can lead to a loss of privacy. Unfortunately for you, it seems like in your case all the outputs do belong to a single address.

In the case of electrum, this doesn't appear to be a configurable option, although you could notice it is happening prior to submitting the transaction by using the "Preview" option - if you notice that the total fee or size or number of inputs consumed it too large, you can force electrum to build a transaction using only specific inputs by selecting them in your transaction history, then right clicking and selecting the spend from option.


How many FPGA can be attached to one computer?

From what I know, you can connect basically any amount of FPGA cards to one computer through USB hubs. Case in point:


How many Watts can I safely draw from a typical US home circuit for Bitcoin mining?

There isn't a single "standard" for residential circuits in the U.S. but there might be a typical circuit, such as 20 amps.

As far as plug connections, don't use light-duty extension cords; make sure they are rated for high amperage, say 20amps.  Generally if you are plugging directly into an outlet then the total power drawn can be done safely up to 80% (rule of thumb) of the level the wiring is rated for.

If the circuit breaker is 20 amps and the circuit is using the proper gauge wiring for that and was wired properly, then you should be able to draw 16 amps safely from it.

16 amps * 120V = 1,920 watts.

So you could add a smaller capacity rig on the same circuit but you cannot have more than one of those 1.2 kWh rigs on what might be a "typical" residential circuit.

[Disclaimer: I'm not an electrical engineer nor an electrician but I play one on Bitcoin stackexchange.]


In your script the previous ScriptPubKey is different.
If you want create custom script you need to sign manually the transaction, you can't use signrawtransactionwithkey. Bitcoin core sign only the standard transaction


in bitcoin core, how to use Tor for broadcasting new transactions only?

You cannot.
The node side of Bitcoin Core treats wallet transactions as any other transaction. They aren't treated any differently from transactions received over the network. So once the transaction is added to the node's mempool, it will be broadcast to connected nodes in the same way that any other transaction would be relayed.
All you can do is to temporarily run Tor only for transaction broadcast.


When purchasing an item through BitPay, how do their exchange rates compare with the market exchange rates?

Their website does have the methodology by which the exchange rates are calculated.


Take a look: https://developers.coinbase.com/api/v2#rate-limiting

The limit is quite high, it is really strange you received an error response. I suggest you to contact their support, and meanwhile changing your API key (if you're using one) could be a good idea.


How to create multi-user bitcoin wallet using UTXO?

I'm assuming that you're using a fully custodial setup. You need to implement logic to keep track of their balances in a database. Hereby, you give each new user a new deposit address and keep track whom you have shown which addresses. When you receive funds, you credit the corresponding user in your database. When they withdraw, you deduct from their balance. Hereby, you need to consider the confirmation status and transaction fees of the corresponding transactions.

To be honest, if you're having trouble mapping individual user balances to your customers, it worries me that you are aiming to manage funds for others.
You should perhaps consider relying on a third party service to manage the funds of your business for you. However, even then you'll need to implement the basic business logic yourself.


What does it mean that ripples are destroyed?

Nobody gets that fee, as simple as that.

To protect the XRP Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of XRP. This transaction cost is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network.
Every transaction must specify how much XRP to destroy to pay the transaction cost.

See the Ripple Developer Center for further details.


Regarding Stellar as an Alternative currency transaction manager

(Full disclosure:  I work for Stellar.org)

I'm not quite sure what you mean by "We also are based on the lets system with equal positive and negative balances.", so I cannot comment on how that effects Stellar's viability for your problem, but I can talk about the transaction fee you would require.

As of now (December 2015), the stellar network itself only has support for the native transaction fees used for spam prevention.  This means that you would have to implement your own support for transaction fees.  Let me describe how one such system might work on the stellar network:

Since the stellar network doesn't have support for collecting a transaction fee at the time of payment, you must instead collect transaction fees after the fact.  Members of this system would be invoiced by you with their billed fees, and they would pay to keep their account in good standing.  When an account is not in good standing, your system would revoke access to your currency (see "Controlling asset holders" at https://www.stellar.org/developers/learn/concepts/assets.html for details) that would prevent the account from making or receiving payments in your currency until you restore access.

Now, such a system is definitely more complicated than if the stellar network handled custom transaction fees natively, but our intention is to keep the core stellar network as simple as possible, and one of the features that got chopped was support for asset-based transaction fees.  Luckily, this is a great opportunity for a group of developers to build a helper service to support this use case.  Tracking payments on the stellar network and managing an account's standing based upon a set of customizable business rules seems like a generically useful tool to have available for developers and could benefit a large range of use cases, from custom currencies to e-commerce systems, to even something crazy like a stellar-funded metered power grid.  I'd be happy to discuss such a solution further if you're interested.


How is bitcoin sent into my bank account?

Traditional banks don't hold bitcoin in their accounts, so you can't send bitcoin to your account.  What you can do is sell your bitcoin for fiat currency and have that fiat deposited into your bank account.  There are many companies willing to buy your bitcoin for fiat currency.

As for giving out your address for a transaction, that is not something you need to do when you are sending bitcoin to someone.  Bitcoin is a system where you push funds to someone, rather than give them the credentials to pull them from you.  Afterwards, they will be able to determine your address, but that isn't really the mechanism you use to pay someone, nor is it important to the recipient.  This is similar to if you pay someone with cash.  Afterwards they will be able to see the serial numbers on the bills, but they don't care, nor were those numbers needed by them for the transaction to occur.


Yes, as long as you close the Bitcoin program first, you can copy the wallet.dat file anywhere you want to back it up. Just remember to keep it safe and use a password, and your Bitcoins will be safe. If you lose the wallet, you will lose the bitcoins you have in it forever (there is no option of recovery of lost bitcoins, unless you are talking about recovering lost files from your hard drive).