What is the O(n^2) signature hashing problem and how does SegWit solves it?

Moving signatures to a separate field does not actually solve it. However one of the things that segwit did was to redefine the message that is hashed and signed. This is specified in BIP 143.

Signature verification requires three things: the public key, the signature, and the message that was signed. In Bitcoin, the public key and the signature are provided by the person spending an output (or in some cases the public key is provided in the output itself). What is missing is the message. Instead of having a user provided message, the message is actually the spending transaction itself or some variation of it. How this message is constructed is known as the signature hashing algorithm.

For non-segwit signatures, the message is typically the entire spending transaction with all scriptSigs empty except for the input that the signature will belong to. That input will contain the scriptPubKey of the output being spent. The important thing to note here is that the message contains all of the prevouts that are specified. And every single signature signs a similar message, but still has all of the inputs in each one.

If you were to add another input, this not only adds another signature that must be done, but also it increases the size of the data that must be hashed for every single signature in the transaction. This means that if a transaction has n inputs each requiring 1 signature (thus n signatures required), for every signature, n inputs must be hashed. This is done n times so every input is hashed n*n = n^2 times. Thus it is quadratic.

However segwit defines a new signature hashing algorithm for segwit inputs. The message that is signed is not the spending transaction with modifications, rather it is a completely different structure which contains data pulled from the transaction.

From BIP 143, the data that is serialized and then hashed is:

     1. nVersion of the transaction (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
     4. outpoint (32-byte hash + 4-byte little endian)
     5. scriptCode of the input (serialized as scripts inside CTxOuts)
     6. value of the output spent by this input (8-byte little endian)
     7. nSequence of the input (4-byte little endian)
     8. hashOutputs (32-byte hash)
     9. nLocktime of the transaction (4-byte little endian)
    10. sighash type of the signature (4-byte little endian)

The important thing to see here is that this by itself does not increase in size when more inputs are added. Almost everything has a fixed size, with the only thing having variable size being the scriptCode.

Now you may notice that this does contain hashPrevouts and hashSequence which are the hash of the prevouts and the hash of all of the sequence numbers, respectively. The amount of data that is hashed for these hashes will grow as more inputs are added. If implemented naively, signing and verifying segwit inputs would still be quadratic.

But by specifying the hash of the prevouts and the hash of the sequence numbers separately instead of interspersed throughout the message as non-segwit does, these hashes can be precomputed once and then reused for every signing and verifying operation in a transaction. Thus this allows for an optimization which makes this linear.

At signing or verifying time, the signer or verifier can first compute hashPrevouts, hashSequence, and hashOutputs once. These values remain the same for all inputs. Then for every signature, they compute the sighash which does not end up re-hashing the majority of the data and does not typically change in size from input to input. Thus since the amount of data being hashed really only changes when the transaction gains an input, and it only changes by a relatively fixed amount, segwit sighashing is linear.


Why do some outputs have a zero value and no address?

The outputs have no address because they are data-carrying outputs.

  {
     "spent":false,
     "tx_index":80899271,
     "type":0,
     "value":0,
     "n":3,
     "script":"6a144153435249424553504f4f4c5245474953544552"
  }

The script argument is the serialized equivalent of

OP_RETURN 4153435249424553504f4f4c5245474953544552

(The hex decodes to "ASCRIBESPOOLREGISTER")

OP_RETURN means that all attempts to spend this output will fail. This can't be spent, so there's no point in putting money in it - it would just be lost.


How does this OpenCL BTC private-key cracker work? Is it a real threat to bitcoins?

I hope this post by Greg Maxwell is convincing enough: https://bitcointalk.org/index.php?topic=421842.msg4809012#msg4809012

Unless your private key is generated by a weak random number generator, there is no need to worry. It effectively takes around 10^42 operations to crack a 256-bit elliptic curve private key.

He's using names of some well-known algorithms for solving the discrete logarithm problem (which is what you must do to find the private key from a public key in our case). They are significantly faster than a brute force search, but cannot break the limit posted above.

The explanation seems to boil down to "we pick some keys to start with, and if yours is close to any of them, we'll find it quickly". That shouldn't surprise anyone. The odds of being "close" to any of the keys someone chooses to start with are astronomically small however. Even being able to try millions or billions of keys per second will not change that.


how easy it is to use Copay as a wallet that we can both share,

copay.io says:

Copay is a true bitcoin wallet, not an account service. Secure your personal funds with multiple signatures, or just one

See also Multi Sig Use Cases

Multi-Sig Use Cases
m = signatures required to spend,  n = signatures possible
m=1 and n>1
Shared Wallet
Could be used for small group funds that do not require much security. Least secure multi-sig option because it is not multi-factor. Any compromised individual would compromise the entire group. Group funds for a weekend or evening event might be a good use case. A shared wallet might also be fun for some kind of games too. Besides being convenient to spend from the only benefit of this setup is that all but one of the backup/password pairs could be lost and all of the funds would be recoverable.
m=n
Partner Wallet
Scary because no keys can be lost. As the number of signatures required increases the risk also increases. Could be thought of as hard multi-factor authentication.

etc
Note that terms like "partner wallet" or "buddy wallet" are not generally used and understood. People are more likely to call this something like a "2 of 2 multisignature wallet" or a "1 of 2 multisignature wallet" respectively. Though the above terms are more general and usefully apply to many other values of m & n.

There have been desperate questions here from people who set up a 2-of-2 multisignature wallet and found their friend lost their wallet-password without making any backups. This meant all their Bitcoin became lost forever. So I'd suggest
Go for a 2-of-3 arrangement with a passive partner (someone you both trust not to use their signature except in pre-agreed  emergency
circumstances. e.g. create a third key with your friend, and lodge the key, written on paper in a sealed envelope, with a lawyer)
If you must go for 2-of-2, walk through the backup and recovery process with your friend and make sure both of you are aware of the risks of not making a backup, or of not having tested recovery. You could easily lose all your money through a bit of carelessness on your friend's part.

I can't really answer "how easy" since I don't use it and that is rather subjective anyway.
Copay appears to be a popular wallet. It ought to be well-tested by it's users. It's probably worth trying out. If you find it doesn't meet your ease-of-use needs, you can always move your funds to a different wallet or import the private keys into a different wallet (saving tx fees).


Bitcoin Core not showing content of address

download of the latest blockchain info, importing the wallet,

If you did it in that order you probably need to rescan using the console or command line options.

rescanblockchain ( start_height stop_height )
Rescan the local blockchain for wallet related transactions. Note: Use
"getwalletinfo" to query the scanning progress.
Arguments:

start_height    (numeric, optional, default=0) block height where the rescan should start
stop_height     (numeric, optional) the last block height that should be scanned. If none is provided it will rescan up to the tip at
return time of this call.


Compatibility questions regarding Native Segwit addresses

Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.
The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.

Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on Bitcoin Optech's Compatibility Matrix or whensegwit.com.

My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.


Why are fiat Currencies inflationary and Bitcoin deflationary?

There are many causes for inflation, but the two most often agreed upon, according to Investopedia, are these:

  Demand-Pull Inflation - This theory can be summarized as "too much
  money chasing too few goods". In other words, if demand is growing
  faster than supply, prices will increase. This usually occurs in
  growing economies.

  Cost-Push Inflation - When companies' costs go up, they need to
  increase prices to maintain their profit margins. Increased costs can
  include things such as wages, taxes, or increased costs of imports.

Fiat currency inflation absent these forces can be driven by the creation of money through speculative fractional reserve bank lending practices as well as simple "printing of money" by the central bank responsible for a government's currency. It is in the interest of the government's ability to spend that it be able to freely create money out of nothing, which is the veritable definition of fiat, Latin for "let it be".

Advantages of inflation include:

Steady rise in prices
Steady rise in value of non-liquid assets, e.g. not cash
Supposedly an indicator of growth

Disadvantages of inflation include:

Cost of goods increases because one unit of money does not have as much purchasing power as it did previously
Decrease in the value of stored liquid assets, e.g. cash in a non interest-bearing account
Potential for hyperinflation

Bitcoin's deflationary quality is based on the assertion that a currency must have scarcity in order to be valuable. By limiting what amount can enter the system, it ensures that no individual can increase the supply and inflate the value relative to physical goods.


can sender send 2 amounts to single recipient in single transaction?

Yes. This sort of transaction is doable in bitcoin.

A point which I would like ot highlight is that transaction fees in bitcoin are proportional to the transaction size in bytes(and not the amount being sent). So, splitting the amount into 2 outputs will cost you more than combining the outputs.


Which cryptocurrency has the smallest block time?

There was a coin called Flashcoin that tried to do 6-second block times. I don't think that's being actively mined anymore as another Flashcoin appeared a year later (60-second block times).

Ethereum is planning a 12-second block time. Vitalik makes an argument for why that's probably the minimum for now here. Of course, ethereum hasn't been released yet, but Fastcoin with its 12-second block time is probably considered the lowest block generation time currently.


There are two possible actors that may build a ticker: exchanges and observers.

Exchanges actually perform trades on their platform so they'll likely be using the last price a trade was performed as the current price.

Observers do not trade themselves and will have to rely on exchanges to get the raw data on trades. They'd then pick the last trade price for each exchange and combine them into a single value. A wide range of schemes is available to merge the values. CoinDesk for example uses an average weighted by an exchanges daily volume.


Electrum Wallet - Is it possible to specify inputs in new transaction?

Use the secondary click on a address and then the "Send from" option.


Can I look for transaction in the genesis block?

There are no other transactions in the Genesis block. For all intents nothing in that block is worthwhile inquiring information about.


You should try adding daemon=1 to your bitcoin.conf file.


This transaction is not signed. It is not valid and I cannot find it on my testnet node nor on any testnet blockchain explorers. The signature takes up the bulk of the bytes in a transaction, so this is expected behavior.


bitcoin sent from coinbase will come from a wallet they control. if you sent bitcoin or bitcoin cash back to it they now control those funds.

the proper course of action is to document the process, what addresses was used, which transaction ids was assigned and what blocks did the transactions get mined in, then contact coinbase customer support and request that they help forward those funds to an address you control.

do it as soon as you can, but be aware that you might have to wait until coinbase supports BCH to withdraw them.


Are all three Bitcoin address types interoperable (legacy, segwit, native segwit)?

At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them.

Wallet software may of course have restrictions, but these are usually not about combinations. E.g. some wallets may be unable to generate a p2sh-segwit address to receive on, or be unable to send to bech32. However, I have not heard about software that puts restrictions on where it can send to based on what is being spent, for example.


What is [::]:0 address in bitcoin debug.log?

[::] is IPv6's version of localhost (0.0.0.0).


Creating a nothing-up-my-sleeve public key

I was told that the minimum number is 0.

That is correct. 0x3400000000000000000000000000000000000000000000000000000000000000 is a valid x-coordinate on secp256k1.

  My understanding is that the answer is supposed to be like this: '0434' + hex(n) + y_value. I am not sure how to approach this

That is also correct. However, you will have two y-coordinates. One even and one odd and hence two uncompressed public keys. That is the reason why we append a prefix to the x-coordinate to tell us whether the y-coordinate associated with that x-coordinate is even or odd.

  Is it true that x-coordinate is supposed to be 32 bytes and y coordinate 32 bytes too?

That is the maximum size. It can be below that as well.

  Is it true that each coordinate is represented in hex mode of 64 chars?

Related to to above. One byte representation needs two hexadecimal characters.

  Python code

I'll use the below one.

p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
def modular_sqrt(n, p):
    ''' Find a quadratic residue (mod p) of 'n'. For Bitcoin p is an odd prime, that satisfies
        the identity p % 4 == 3. As a result, this is a simple solution where the modular square
        root of y^2 is : y = pow(y^2, (p + 1) // 4, p).
        If p did not satisfy that identity we would have had to use the Tonelli-Shank's algorithm
    '''
    return pow(n, (p + 1) // 4, p)

def y_coordinate_from_x(x_coordinate_with_prefix):
    public_key_x_coordinate = int(x_coordinate_with_prefix[2:], 16)
    public_key_y_coordinate_sign = int(x_coordinate_with_prefix[:2])
    y_squared = (public_key_x_coordinate**3 + 7) % int(p)
    public_key_y_coordinate = modular_sqrt(y_squared, int(p))

    # check the sign (odd or even) and match that to the sign provided by x-coordinate
    sign_check = 0 if public_key_y_coordinate_sign == 2 else 1
    if int(str(public_key_y_coordinate)[-1:]) % 2 != sign_check:
        public_key_y_coordinate = int(p) - public_key_y_coordinate

    return '%064x'%public_key_y_coordinate

x = '3400000000000000000000000000000000000000000000000000000000000000'
y1 = y_coordinate_from_x('02' + x)
y2 = y_coordinate_from_x('03' + x)

so your uncompressed public keys are '04'+x+y1 and '04'+x+y2


1. You will never be able to re-mine the previous block and get more fees.
Since Bitcoin Core 0.11.0 (July 2015) transactions include a nLockTime to discourage fee sniping and ensure they can only be mined at a height greater than current head. Their fees can only be collected by moving forward and not by undercutting previous block. Although adoption is not widespread, you can expect it to be if this threat became credible. Also, a chain leaving less fees for the next miner will be less attractive for other miners to continue.
This would be the opposite case to the attack described in the mentioned paper, which consists on re-mining a block to claim less fees and incentivize other miners to continue it instead of the honest one.
2. Mempool will not be shallow enough for consecutive blocks to have significantly different reward.
Marginal utility of transactions decreases as fees get more expensive, so Bitcoin users face a trade-off between waiting a bit longer for block inclusion (until congestion subsides) or pay higher fees.
We can observe that the more transactions are queued in the mempool, the higher and flatter is the fee slope, and the lower will be the difference between contiguous block rewards. This is due to abnormally high fees of high priority transactions published between blocks (that heap on the left of the charts) representing a smaller fraction of the total reward.
Check the clear cut at 250 sat/WU for most transactions of December 22, 2017. Most people is not in such a hurry for transaction confirmation after all when fees become significantly high, and they will be willing to pay little more for their transactions to be mined in 6 hours time instead of 7 hours.

Rewards immediately after a block is found are certainly NOT zero, "making it unprofitable for any miner to mine", as they claim.
3. Miners can always hedge undercutting risk.
Miners could include an anyone-can-spend output in their blocks, as a premium to mitigate the risk of other miners undercutting them, when their rewards are much more valuable than the fees remaining in the mempool. So, there is no need to alter transaction selection to make this possible.


Why is 550 (MiB) chosen for minimum storage size for prune mode?

Just got help from someone at BitcoinTalk forum, who directed me to bitcoind 0.11.0 changelog (Which pruning was introduced/implemented for the first time in bitcoind)

As indicated there, Block pruning deletes raw block & undo data:

  ...
  there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data. Block pruning allows Bitcoin Core to delete the raw block and undo data once it's been validated and used to build the databases
  ....

which then explains where the number 550 (Not magic anymore!) has come from:

  The minimum allowed is 550MB*. Note that this is in addition to whatever is required for the block index and UTXO databases. The minimum was chosen so that Bitcoin Core will be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 minutes per block). In rare instances it is possible that the amount of space used will exceed the pruning target in order to keep the required last 288 blocks on disk.

*Typo! MiB(1024) is right & not MB(1000). So:

550*1024*1024 = 576716800
576716800 / 288 ~ 2MB

Let me append it that with release of bitcoind 0.12.0, Wallet functionality & block relay that was disabled at pruned mode(& I talked about in my question), are supported again.


It is possible to use without an account.
Just use "" as from-account.

Example:

sendmany "" '{"mzjqvrPTipexdXzJbCjZExs8keg7nMf4M3":0.01,"mqQ69fPZEeJomEzG85FHfrKQ66x3w6oXwp":0.02}'

Watch out: It will tell you Account has insufficient funds (code -6) when you not have enough funds even if you don't use accounts.

Help:

sendmany "fromaccount" {"address":amount,...} ( minconf "comment" ["address",...] )

Send multiple times. Amounts are double-precision floating point numbers.

Arguments:
1. "fromaccount"         (string, required) DEPRECATED. The account to send the funds from. Should be "" for the default account
2. "amounts"             (string, required) A json object with addresses and amounts
    {
      "address":amount   (numeric or string) The bitcoin address is the key, the numeric amount (can be string) in BTC is the value
      ,...
    }
3. minconf                 (numeric, optional, default=1) Only use the balance confirmed at least this many times.
4. "comment"             (string, optional) A comment
5. subtractfeefrom         (array, optional) A json array with addresses.
                           The fee will be equally deducted from the amount of each selected address.
                           Those recipients will receive less bitcoins than you enter in their corresponding amount field.
                           If no addresses are specified here, the sender pays the fee.
    [
      "address"          (string) Subtract fee from this address
      ,...
    ]

Result:
"txid"                   (string) The transaction id for the send. Only 1 transaction is created regardless of
                                    the number of addresses.

Examples:

Send two amounts to two different addresses:
> bitcoin-cli sendmany "" "{\"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ\":0.01,\"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz\":0.02}"

Send two amounts to two different addresses setting the confirmation and comment:
> bitcoin-cli sendmany "" "{\"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ\":0.01,\"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz\":0.02}" 6 "testing"

Send two amounts to two different addresses, subtract fee from amount:
> bitcoin-cli sendmany "" "{\"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ\":0.01,\"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz\":0.02}" 1 "" "[\"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ\",\"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz\"]"

As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendmany", "params": ["", "{\"1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ\":0.01,\"1353tsE8YMTA4EuV7dgUXGjNFf9KpVvKHz\":0.02}", 6, "testing"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
 (code -1)


Recover Old Bitcoin Wallet (Currently getting a Segfault)

You may find the following post relevant:

Wallet.dat (<0.4.0) format: retrieving Bitcoin, possible security concerns

This post details some of the steps you may need to perform to import the wallet into a current client, the biggest time consumer will be waiting for the full blockchain to sync with the current network.


Blockchain.info testnet websocket doesn't work

~> curl --head https://testnet.blockchain.info
HTTP/1.1 503 Service Unavailable

It's likely the service just isn't something that exists.


Struggling to successfully broadcast a p2pkh transaction

Nevermind.

I combined the two answers from these posts and managed to get something working:

Redeeming a raw transaction step by step example required

https://bitcoin.stackexchange.com/a/41226/89247

Yes. You can use compressed public keys with p2pkh. There are no restrictions.


Java: bitcoinj; how to download a full block?

Example in bitcoinj source code is exactly what you are looking for:

BriefLogFormatter.init();
// Parse command line arguments
OptionParser parser = new OptionParser();
OptionSet opts = null;
List<String> nonOpts = null;
try {
    parser.accepts("localhost", "Connect to the localhost node");
    parser.accepts("help", "Displays program options");
    opts = parser.parse(args);
    if (opts.has("help")) {
        System.out.println("usage: org.bitcoinj.examples.FetchBlock [--localhost] <blockHash>");
        parser.printHelpOn(System.out);
        return;
    }
    nonOpts = opts.nonOptionArguments();
    if (nonOpts.size() != 1) {
        throw new IllegalArgumentException("Incorrect number of block hash, please provide only one block hash.");
    }
} catch (OptionException | IllegalArgumentException e) {
    System.err.println(e.getMessage());
    System.err.println("usage: org.bitcoinj.examples.FetchBlock [--localhost] <blockHash>");
    parser.printHelpOn(System.err);
    return;
}

// Connect to testnet and find a peer
System.out.println("Connecting to node");
final NetworkParameters params = TestNet3Params.get();
BlockStore blockStore = new MemoryBlockStore(params);
BlockChain chain = new BlockChain(params, blockStore);
PeerGroup peerGroup = new PeerGroup(params, chain);
if (!opts.has("localhost")) {
    peerGroup.addPeerDiscovery(new DnsDiscovery(params));
} else {
    PeerAddress addr = new PeerAddress(params, InetAddress.getLocalHost());
    peerGroup.addAddress(addr);
}
peerGroup.start();
peerGroup.waitForPeers(1).get();
Peer peer = peerGroup.getConnectedPeers().get(0);

// Retrieve a block through a peer
Sha256Hash blockHash = Sha256Hash.wrap(nonOpts.get(0));
Future<Block> future = peer.getBlock(blockHash);
System.out.println("Waiting for node to send us the requested block: " + blockHash);
Block block = future.get();
System.out.println(block);
peerGroup.stopAsync();


Bitcoin automatically diverted to bech32 address

I'm sorry to be the bearer of bad news: It looks like your funds are gone and the security of your computer is compromised. A quick google suggests that is one of the electrum phishing destination addresses.

You can find more information on the attacks against electrum here: http://electrum-malware.surge.sh/


Can the Government step in, to ban bitcoins?

I think that banning bitcoins and enforcing the ban would be a huge endeavor. It would be expensive and probably politically unpopular. See this question: How much would it cost for a government to undermine Bitcoins? Also see What methods could a government use to shutdown Bitcoin?


download it from the official website :

https://bitcoin.org/en/download

for windows 64 bit:  https://bitcoin.org/bin/bitcoin-core-0.13.1/bitcoin-0.13.1-win64-setup.exe


Miners are free to mine empty blocks if they want. They do not HAVE to include transactions in them. Any block that is well-formatted and extends the blockchain is valid. Miners who do that (mining empty blocks) get the coinbase transaction (12.5BTC) and don't have to deal with the "hassle" of checking pending transactions. They lose the potential transaction fees though (much less than the reward).

Sure, if every miner did that, the bitcoin system would be over.


Which mobile apps (android) and desktop apps can I use to connect to this node without running a full node/ daemon on the desktop or mobile?

Mobile apps:
Good UI/UX for using bitcoin core.
https://github.com/Fonta1n3/FullyNoded (iOS)
It's a simple app to connect to local node for broadcasting transaction. You can add more things if you are a developer.
https://github.com/percy-g2/BitK (Android)
Desktop apps:
https://github.com/cryptoadvance/specter-desktop
https://github.com/bwt-dev/bwt-electrum-plugin (Connect Electrum with bitcoin core full node)


BlockNotify/WalletNotify - but without the console window

I took me some, but I think I have an answer. I went trough the source code and found the runCommand() function that actually starts the command provided by notify options (it is called mostly from main.cpp and the code runs in a separate thread).

From util.cpp

void runCommand(std::string strCommand)
{
    int nErr = ::system(strCommand.c_str());
    if (nErr)
        LogPrintf("runCommand error: system(%s) returned %d\n", strCommand, nErr);
}

It uses the standard C library method system(), which is probably giving you the flashing window. Normally one would use CreateProcess() (or similar) to prevent the flash effect and have much more control over the spawned process (I don't know why the developers chose system() here, but I guess it was just easier). I believe the behavior of the system() call is system dependent.

Also, when you say bitcoind, you mean the CLI interface of bitcoin, right? Is there a bitcoind console window running? As for a solution, you could edit the source code to use CreateProcess() with the DETACHED_PROCESS flag, that would do the trick.


i lost my password and 12 word can i recover my password?

The only option left is to contact the support: https://blockchain.zendesk.com/


Why do outputs need to be spent entirely?

It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)

There is no such thing as an accounts "balance". It only exists implicitly.

When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a special script language, the person making the transaction can specify the requirement for spending that output. There's a whole range of options you have to specify this.

The most common output script is something that holds the following condition "to spend this transaction, the spender must sign this hash with the private key from this address". So this basically means that the owner of that address can spend it. This are the type of outputs that you will probably generate when you "send money to an address". They are called pay-to-pubkey-hash transactions.

Other possible output scripts can be stupid things like "anyone can spend this" to very complex things like "at least 3 of the private keys of the following 5 addresses must sign this hash", which is a so-called m-of-n transaction.

This brings us back to balances. When your wallet app says you have a balance of X btc, it just searches all unspent outputs that you are able to spend with your private keys; this are all pay-to-pubkey-hash transactions with one of your addresses in them.

Now, when you want to spend some of the money from your "balance" and send it to an address, you will need to make a transaction. The way transactions are created is as follows:

Take a number of unspent outputs from previous transactions and use them as inputs.
Make a new output of which the output amount is equal or less than the sum of all input values. Your wallet will most probably make this output a pay-to-pubkey-hash output to the address you wanted to send money to.
Because probably the inputs will not exactly match, you will add another output so that the sum of all new outputs is equal to the sum of the inputs. This output will also be a pay-to-pubkey-hash output to a new change address or to the same address as you are spending from (different wallet apps do this differently).
Note that if the total output amount is less than the total input amount, the difference is considered the transaction fee and this will go to the miner of the block your transaction will appear in.
Then lastly the wallet app has to prove it has the right to spend the inputs you used in the transaction. It can do this to provide an input script (technically it's called a scriptSig). For the common pay-to-pubkey-hash, this script will contain your public key and the signature you made with your private key. This input script is used by miners to verify if you have the right to make this transaction.
The transaction is then broadcast to the Bitcoin network.

After this transaction has been received by other clients and is verified by a miner, all clients will remove the outputs used in the transaction from their collection of "unspent outputs". So if you would try to spend it again, that won't be possible because miners will not accept it because the output you want to spend does not exist.

I hope you can understand that using this methodology, it is not possible to do a thing like "subtract the amount from person A's balance and add it to person B's balance". When making transactions, you basically destroy some outputs to generate new ones.


where to get specifications about how to make a block in bitcoin mining

You'll need to hash the block header, which is actually made up of 6 items: the version bit, the hash of the previous block, the merkle root of transactions you're including in your block, a timestamp, a target difficulty, and a nonce value. This page on the bitcoin wiki contains more info, I think you'll find it helpful.


Installed Bitcoind on my Ubuntu server, but where does the blockchain get downloaded?

Based on the bitcoin wiki, it is shored here

Linux
By default Bitcoin will put its data here:
~/.bitcoin/


What is a good hardware for a lightning network node?

Lightning itself is a pretty lightweight protocol and can easily be run on a raspi 3. However without neutrino a lightning node needs to have access to a Bitcoin full node. Most people seem to run the Bitcoin node on the same machine as the lightning node. While a raspi3 can run both the processor is a little week to verify the entire blockchain. So expect a long time (couple of weeks) for initial blockchain sync or run a remote Bitcoin node.


The base system is described in BIP32 and BIP39.

Essentially, the conversion goes the other way around. We don't convert a list of addresses to a seed. A seed is converted to a list of addresses.

BIP32 described how hierarchical deterministic (HD) wallets work.

BIP39 describers how these can be encoded into mnemonic phrases, or seed words.

There's an excellent open source tool by Ian Coleman - BIP39 that lets you play around with the various derivation and entropy options. You should, however, be wary of entering any seeds containing funds or using it to generate secure seeds, as always.


What makes an unconfirmed tx 'suspicious'? (likely to be replaced or never confirm)

Replacing transactions without confirmation is relatively easy.
I would tag every transaction without confirmation as "suspicious".

RBF is a policy and miners could also replace transaction that do not sign opt-in-RBF.

Best way to check if a 0-conf transactions will be mined soon:

check nSequence number (only accept 0-conf if nSequence number is INT_MAX)
check the transactions fee-rate and compare it with your estimated fee (requires a mempool/bitcoin-core)
Calculate the risks: every 0-conf transaction can be replaced/double-spent! High value items should not be "dispatched" < 6 confirmations (IMO).


New offers and orders are matched respectively with the best order and offer available until they are fulfilled. If there is more than one entry at the same price, the oldest entry will be matched first. If a new entry cannot be matched completely, it will remain in the order book until the remainder is matched or it expires.

See an example below:

The initial order book

Offers:

[Bob] sell 1 BTC at $1000
[Charlie] sell 2 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

Orders:

[Fabienne] buy 1 BTC at $999
[George] buy 1 BTC at $998
[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996

Alice wants to buy some Bitcoins.

Alice wants to buy 2 BTC and is willing to pay up to $2020. She adds an order for 2 BTC at $1010.

The system will now try to match her order to offers already in the system, of course matching the best offer first.

As seen above, Bob is offering to sell at $1000 and Charlie offers to sell at $1001, her order matches with Bob's offer using it up completely. Her order has a second BTC though, which will be matched against Charlie's offer next, because Charlie entered his offer before Dolph, who is offering the same price.

After Alice's order was matched there are the following offers:

[Charlie] sell 1 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

and the following orders:

[Fabienne] buy 1 BTC at $999
[George] buy 1 BTC at $998
[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996

Note that Alice's order and Bob's offer are gone, and Charlie's offer is reduced by 1 BTC.

Afterwards, Jeremy wants to sell some Bitcoins

Now Jeremy wants $9,970 and has 10 BTC for sale. He creates an offer for 10 BTC at $997. Currently there are only two orders that will buy at or over that price: His offer matches the orders of Fabienne and George. He gains $999 and $998 for two of his BTC, the remaining 8 BTC will stay as an offer.

After Jeremy's offer was partially matched there are the following offers:

[Jeremy] sell 8 BTC at $997
[Charlie] sell 1 BTC at $1001, [Dolph] sell 1 BTC at $1001
[Emilio] sell 1 BTC at $1002

and the following orders:

[Harry] buy 1 BTC at $996, [Ivan] buy 5 BTC at $996


Following the steps from "How to claim your Bitcoin Cash (Bcash)" by Trezor Blog should do the trick.

https://blog.trezor.io/claim-bcash-bitcoin-cash-bch-bcc-trezor-wallet-f0a810d5864a

Steps:

1) Make sure Trezor uses latest firmware

2) Connect your Trezor

3) Go to Coin splitting tool

4) Receive your Bitcoin Cash


USB ASIC miners require some sort of control program that sends work to the miners and collects the results. You set them up in that control program. BFGMiner is one such program.


How do you merge mine rootstock with bitcoin on an Antminer?

The easiest way is to join a pool that merge mines what you want, in this case Rootstock.

If you want to run your own pool, make sure the pool software supports the type of merged mining you want to do. Then set it up as described in to the documentation.

Rootstock is not live yet, but many pools are testing it, so you should have several pools to choose from.


Windows 8 is just like Windows 7.

But on a mondern bitcoin-core installation you will be asked where to put your data-directory. So if you changed the default path you need to consider that.

So if you found your data directory, your wallet.dat file is right there. Make a backup or restore it as you wish.

There is also a good tutorial video around for more visual explanation.

For a more detailed explanation on what steps are required to restoring your wallet.dat you can check out this post.


Market laws suggest that if said person would use his 1000x more efficient miner in any non-trivial scale, he would push other miners out of the market. The difficulty would steadily increase and other miners would be operating at a loss.
So I guess the answer is yes, other people would notice if such thing happened.


How do big sites/markets handle the intrinsic "transaction fees"?

Take a look at the Bitcoin wiki page on Transaction Fees.

First of all, a transaction fee is not always required. Miners decide whether to accept transactions without a fee and most miners follow the same decision protocol for that.

  A transaction may be safely sent without fees if these conditions are met:

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

The priority basically adds the notion of age. Outputs that are created some time ago can mostly be sent for free. Very young outputs cannot be spent free. This is to prevent someone from spamming the blockchain with consecutive transactions.

  Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

So this basically means that the fee increases as the transaction size increases. Considering this, it is not a good solution to add thousands of inputs and outputs to a transaction.

I believe the best solution for a service like a market is to try to make as much as possible free transactions. A typical single-input-single-output transaction is 500 bytes. When you always use the oldest outputs available in your hot wallet pool, you can try to always create 10KB transactions that are free.


Fundamental Question on Bitcoin: How would one convert his "bananas" into bitcoins?

how would one transact his/her hard money or the farm
  products (say bananas)

It is not possible to transact/transfer/convert bananas to anything else. The same situation is with any other things in real and online world.

So, if you have bananas you have only one possibility: exchange them for something to a neighbour. Give me your bananas and I will give you my old shoes. If we are far away to each other, we should construct a chain of exchanges: you sell your bananas to somebody (exchange for your local money), he delivers bananas and sell them to me (exchange for my local money).

  using a basic phone without any banking facility?

We do not need phone and banking at all here. But if you want to use a phone in this chain of exchanges, you may have it in your pocket.


What is the right way to create a MultiSig?

Use the addmultisigaddress nrequired ["key",...] ( "account" ) JSON-RPC command in order to create a p2sh address that will be considered your own.


Here is what I've gathered so far regarding the different version bytes for each type of Litecoin public address:
Mainnet:

p2pkh L-address (LM2WMpR1Rp6j3Sa59cMXMs1SPzj9eXpGc1): 0x30
p2sh deprecated 3-address (3MSvaVbVFFLML86rt5eqgA9SvW23upaXdY): 0x05 (same as bitcoin's mainnet p2sh)
p2sh new M-address (MTf4tP1TCNBn8dNkyxeBVoPrFCcVzxJvvh): 0x32

Testnet:

p2pkh m- or n-address (mipcBbFg9gMiCh81Kj8tqqdgoZub1ZJRfn): 0x6f (same as bitcoin's testnet p2pkh)
p2sh deprecated 2-address (2N2PJEucf6QY2kNFuJ4chQEBoyZWszRQE16): 0xc4
p2sh new Q-address (QVk4MvUu7Wb7tZ1wvAeiUvdF7wxhvpyLLK): 0x3a

This is the Litecoin project's converter between old and new p2sh address format.
And this is an online base58check decoder to check the version byte.


Where are the receiving and sending address descriptions stored?

Yes, all of those are stored in the wallet.dat file. I myself have successfully migrated the wallet file to a new computer and have the addresses and descriptions intact.


From my experience, sometimes the router doesn't actually respond to the UPnP setting for mapping the listening port. What always seems to be working for me is

Shutdown your node (cli stop && shutdown)
Restart your router (usually unplug, wait a minute, replug and wait a few minutes)
Restart node

Regarding the hookup to Samourai, what exactly are your bitcoin.conf settings?


How to generate a valid hash for a bip39 seed phrase?

You can create a valid seed calculating a valid last word (23+1).

Even using the browser JS console:

mywords="sausage liquid same heart ... "

allwords = WORDLISTS["english"]
m = new Mnemonic("english")
for (var w in allwords) {
       curr_word=allwords[w];
       test_words = mywords + " " + curr_word;
       if (m.check(test_words)) { console.log(curr_word) }
 }

Source:

http://wikistas.com/u/cryptodog!Ccsi1HdXWr/Wd5q-generating-secure-bip39-seeds


Send or receive bitcoins with bitcoin-cli without downloading full blockchain

I think you could do what you are asking with an explorer API and rawtransactions, however you need to be careful when using rawtransactions as you could lose a lot of coins if you dont know what you are doing (see my note at the end).

Transactions are made of inputs and outputs.  Lets say you have 10 coins on address A, you could have two unspent transaction outputs (the 2 outputs from when you deposited the 10 coins), maybe one unspent output has 7 coins, and the other 3 coins (totaling 10).

If you want to send your friend 1 coin, you may take the available unspent transaction of 3 coins, send 1 coin to your friend, and 1.9999 coins (after fees of 0.0001) will be returned to you as "change".  Here is an example transaction https://chainz.cryptoid.info/btc/tx.dws?499936575.htm  You can see 1 previous output, becoming the input, and the two resulting outputs.

Your bitcoin-cli wallet needs the full blockchain, because the list of your unspent transactions is constructed from all the inputs and outputs.  However notice that the explorer I linked to also has an API and (if you request and are granted an API key) the following query will result in giving you all the inputs for that specific address;

https://chainz.cryptoid.info/BTC/api.dws?q=unspent&key=(YOUR_API_KEY)&active=18mcGpg2e3Fj6djLxiCbdjgh3cD46VayLC

You then would use the RPC console to:
1/ createrawtransaction
2/ signrawtransaction
3/ sendrawtransaction

Refer to the https://en.bitcoin.it/wiki/Raw_Transactions Wiki for usage and other useful CLI commands around this topic.

WARNING: Note when using createrawtransaction you MUST MANUALLY CALCULATE TRANSACTION FEES AND CHANGE, if you fail to do this correctly change will be consumed as fees!!!

So now you can see how its possible (although extremely awkward!) to make and send transactions without a local copy of the blockchain.  In terms of how a Ledger works, I suspect they do steps 1/ createrawtransaction and 3/ sendrawtransaction in an un-secure environment, they just use the Ledger itself to do step 2/ signrawtransaction, as this is the only point at which private keys are needed.


Transactions from blockchain not confirmed for days

This transaction is not shown on any other block explorer I tried, namely Tradeblock and Blockcypher.

It has most likely been dropped or rejected.


Is there a way to stop someone from giving me bitcoins to an address that I own

No, there is no way to block people sending you bitcoins.  You could, however, send the bitcoins back to the sender.  In fact, you can redeem the transaction output created by the sender in a new transaction, created by you, back to the sender.  This would show that precisely these funds (not just funds to the same amount) were transferred back to the sender.


Is it possible to shorten the blockchain?

it is not possible, because there is no consensus rule who, how and when should do it and how sould others accept "new genesis" block


In my opinion, it is one of the greatest misconceptions about Bitcoin that miners solve a "hard problem". Many news sources explain it like that, but in fact it's not true.

All a miner does is guessing until he got something right. A miners takes his block of transactions (including the coinbase transaction that sends the fees and block reward to himself) and calculates the hash of it. Hash calculation is a very common procedure and is not at all "hard". The hash he gets needs to match a certain condition. This condition gets harder as more miners try it (see Difficulty). When the miner got a hash that fits the condition, he can publish it to all other Bitcoin clients and the block is added to the block chain.

The reason that miners with more computer power have a larger chance of winning the block is because they can simply guess faster. They can calculate more hashes per second to test against the condition, (Mining power is expressed in Hashes/second.)

The need for proof-of-work is there because the Bitcoin protocol wants that a block is found only once every 10 minutes approximately. So, as more miners enter the game, it has to become harder to do. The POW makes sure that finding a block is not easy and takes the some time. That's also the reason that the difficulty raises as more people mine. Every 2 weeks, the algorithms adjusts the difficulty so that again one block is found every 10 minutes at the average hashpower of the previous two weeks.

So, to answer your second question: If you could find an alternative method for achieving exactly the same thing as currently is done in Bitcoin mining, it could replace it. But Bitcoin is programmed as it is and won't probably ever change this method. But there are alt-coins that use different methods for distributing the coins and securing the block chain.


c-lightning channel announcement/establishment issue

When the channel is opened the opening side of the channel chooses if the channel should be private or announced. Well actually the other side can also choose not to accept public channels. Maybe that has happened with both of your channels.
From the information you have we can only guess / speculate.
 If you want to you can try to open a channel with my node (details at https://ln.rene-pickhardt.de - the node does not speak tor tough) but I could look in my logs if necessary and we could together debug what is going on.


Recovered wallet does not contain imported address. How can I recover my funds?

What can I do ...

Re-import the addresses

to recover the funds?

Imported addresses are called "watch-only" or "unspendable" addresses.
If you ever had control over the money at these imported addresses you would have had a private-key somewhere for them.
To give your current wallet control over that money (the ability to spend it) - you must either "import" the private key(s) or "sweep" those private keys into your wallet.
Sweeping private keys is usually considered safer than importing private keys for the reasons demonstrated by your question - imported things are not recovered by using a recovery phrase to recreate the wallet.
The recovery phrase only recovers private-keys and addresses that were generated by the original wallet, not things that were imported into it.
If you don't know the private keys for the imported addresses, there are a couple of possibilities depending on where you got those addresses from in the first place:

You have another wallet that contains those keys
Someone tricked you and you never had any Bitcoin money at those watch-only addresses.

Confusion about the nature of imported addresses is something we often see in victims of fraud.


How to determine the peer/node that created a transaction?

how do you determine if that peer created the transaction or if it is simply relaying the transaction

You cannot, at least not with absolute certainty. This is by design: it helps preserve the privacy of users on the network.

That said, if you decided to run a whole bunch of nodes, and positioned them carefully in the network graph, then you could start to infer where transactions are originating from, based on the timing of your nodes hearing about said new transactions. I think it should be expected that chain analysis firms are doing this today.

To counter this, it must be considered that there are many ways to publish a transaction to the network - the node that first publishes a transaction is not necessarily owned or operated by the user that actually crafted the transaction. For example, today there exists services within the tor network, which allow you to copy/paste a signed transaction into a website form, to be broadcast to the network anonymously. Since you must connect to this service over tor, not even the service provider will know the identity of the transaction's author.

Further work is being done to increase the privacy of transaction broadcast. For example see BIP 156.


Applying additional oauth scopes to coinbase

Old posting, but hit this and this was the first Google result so worth updating.  You can append the meta values to the redirect URL:

 meta[send_limit_amount]=50&meta[send_limit_currency]=USD&meta[send_limit_period]=day

This is buried in the OAuth2 docs on the Coinbase site.


How relevant is the Chinese Great Firewall in the blocksize debate?

Yes, data has shown, that GFW has effects on packet propagation, but not much. The major cause of delay is distance. As you can see here, the median propagation time is comparable for various locations.Complete details can be seen here.

Interestingly, this issue highlights that more than the effect of GFW, it is the effect of large blocks propagation delay & rather serves as a case for even smaller blocks, which Mike was against.

Possible solutions:

O(1) block propagation : "If memory pools were perfectly synchronized and all miners had exactly the same policy for choosing which transactions to include in their blocks and in what order to include them, then miners could just announce new blocks as the fixed 80-byte block header and the coinbase transaction; there would be no need to include any transaction data at all, it could be reconstructed from their peers' memory pools."
Blocktorrent : "a leech(node) will begin to upload chunks of data as soon as it gets them and confirms both PoW and hash/data integrity instead of waiting for a fully copy with full verification."
A miner backbone network : "a hub-and-spoke network, which consists of servers set up in eight well-connected Internet traffic hubs: New York, Seattle, Amsterdam, Beijing, Tokyo, Singapore, Hong Kong and Novosibirsk (located in central Russia). Additionally, the relay network uses a fairly basic compression algorithm. Any Bitcoin node can connect to the nearest hub on Corallo's relay network, and send and receive transactions and blocks to and from other connected nodes."
Cache transaction validation : memoization of transaction validation
Surprisingly enough, blocks smaller than 1 mb!

A duplex payment channel abstraction
Lightning Network

on top of bitcoin would enable off-chain transactions & be like the visa protocol over the fiat layer.

Stratum Mining : The miner in china delegates the block header creation to a server outside china. Probably, the best short-term solution.


Understanding Kraken Trades API (market/limit)

Indeed they don't specify what it means, but the only sane option is that market/limit tag comes from the type of order that closed the deal.

For example there are two lowest sell(ask) orders hanging in the order book:

0.05 BTC at 2000 EUR
0.03 BTC at 2300 EUR

I come to Kraken and place a Market order, buy(bid) for 0.07 BTC, thus the first trade will be for 0.05 BTC, and the second will be for 0.02 BTC. Both will have designation 'market'.

It is possible, however that I want to buy some bitcoin, (let's say 0.9 BTC), but not higher than 2300 EUR. Then to make sure I don't pay more than planned, I make a LIMIT order and the two awaiting orders are matched to mine and what is left of my order amount may hang in the order book on the Buy side. In this scenario the trades as seen via API will have designation 'limit'


Can zero-transactions block generation be called as a Sybil attack?

Can I call such intentional easy-mining a Sybil attack?

No. Because mining is a memory-less process, it is quite possible that subsequent blocks be found while the mempool is empty. Furthermore, the idea that verifying transactions takes away mining resources is moot since the SHA256 hashing is typically done on specialised hardware that can't do anymore than SHA256 hashing, so verification effort and mining effort is mutually exclusive.


Can the signers of a 2 of 3 multisig tx be identified later

When spending a multisig output, the signatures and redeem script are public information.

This allows you to identify:

The number of potential signers
The number of required signatures
Public keys for all potential signers
Which keys signed the transaction (from the signature).

It will not reveal the identity of who owns a public key, unless you have some offchain analysis to go with this data, and already know who owns which public key.


If the nLockTime is less than or equal to the next block height, it can be included in the next block.
To explicitly answer your questions:

The CLTV op restricts the nLockTime field of the spending transaction, therefore if it is set in the past the condition is already fulfilled.
If the nLockTime field of a transaction is set to 500 000 it is valid to be included in any block which height is superior or equal to 500 000.
This basically means any block right now if there is no block chain reorganization deeper than 160 000 blocks :).

This mechanism was cleverly used to discourage reorgs. First introduced in the bitcoin-core wallet, but now most wallets set the nLockTime field of their transactions to the next block.
This prevents, in a future where miners would mainly be compensated for their work by transaction fees, a pernicious incentive to rollback the last block if it included a high fee-paying transaction.


It's best to read through the steps detailed on www.bitcoin.org, they also link to a list of exchanges. A lot of exchanges will require ID verification which may be more hassle than you're willing to go through. But some exchanges do not for smaller amounts. Or you might try to find an Bitcoin-ATM near you.

Exchange and transaction fees will likely be lower than PayPal. And you may lose or gain a bit of value over any Bitcoin leftover in your wallet. Since price fluctuates, you probably want to buy a little more bitcoins than you really need, to make sure you can fully pay the domain name.


Why would a miner mine with a difficulty other than 'the' difficulty?

To understand this we should first explain that a block with a high difficulty, let's say D, is also a share of low difficulty d < D, therefore if we find such a block for difficulty D we automatically have a block of difficulty d. This also means that if I as a miner am looking for a share with difficulty d I might by chance find a block of difficulty D (with the probability d/D). This is exactly the reason why mining pools exist: they assign the miners the task to find blocks of difficulty d in the hope that they will eventually find one for D, i.e., the real network difficulty, which pays for the whole pool operation.

Commonly these blocks at a lower difficulty are called a share, and are used to gauge the hashing rate of the individual miner, giving the pool a way to determine who has what probability of finding the next block and distributing the reward accordingly.


There are two potential ways in which monetary deflation can impact a currency:

1.  Usability

Most modern currencies have a minimum unit, such as the penny in the United States, or the yen in Japan.  If these currencies existed in only finite quantities, then as the economy grew and/or physical money was lost, there might eventually be too few of these units in circulation to allow normal commerce.  Imagine if, for example, the U.S. dollar became so rare that you could buy a car with a single U.S. penny.  How would you buy a loaf of bread?

Bitcoin, however, does not have this problem because unlike the physical currencies of most countries, bitcoins are infinitely divisible.  Even if only one bitcoin remained, it would be sufficient to run a substantial economy on, based on the ability to use tiny fractions of it like the Satoshi.  If even the Satoshi were to become too highly valued/unavailable for commerce, the Bitcoin protocol could be updated to allow even smaller denominations.  So the usability of bitcoins is safe from the effects of deflation.

2. Broader economic consequences from deflation

Many economists believe that deflation is bad for an economy because people will be less likely to invest their money if they can "earn" increased value simply by holding on to it.  Why buy something today, the argument goes, if you could buy it for half as much in a few months time?  Also, taking out loans becomes very difficult, because to be practical they have to have negative interest rates and then why would anyone loan out money in the first place?

However, there is good reason to believe that deflation might not have such a negative effect on Bitcoin.  For one, Bitcoin is unlikely to become the only currency in the world economy, so investments, loans, etc. can simply be denominated in another currency.  But even more importantly there are several concrete examples from history of strictly deflationary currencies.

For example, the Iraqi "Swiss" dinar was a currency that ceased being printed after the first Gulf War, and was left in use only by the Kurdish regions of the country.  With a finite number of "Swiss" dinars in existence, and some being lost or damaged over time, this left the currency in precisely the same state as Bitcoin.  Since it was no longer backed by a government, many economists expected the currency and its economy to collapse.  Instead, the Kurdish economy continued largely as normal for 13 years, and the "Swiss" dinar even appreciated against the "Saddam" dinar that was meant to replace it.

Rick Falkvinge also raises another excellent point regarding deflationary economies.  If, as economists expect, people would decline to buy something today as opposed to next year for half price, then it should be the case that no one ever buys computers, right?  But in fact, the computer industry thrives despite this continued trend of "whatever something costs today, it will cost a fraction of that within a few years".

Ultimately, this is a question for economists to duke out, and you can find more information about how different economic schools approach the problem here.  Suffice it to say, this cannot be considered a crippling fault in Bitcoin as a technology.


Without IP address, are there any other identities considered for banning nodes

First of all, IP addresses are not stored in transactions nor can a node just "generate IP addresses".

How banning works is that nodes connect to each other via TCP sockets which are stream sockets so both nodes know the IP address of the other node. So when a node is banned, the banning node refuses to open a connection to the banned node. Nothing else is involved in banning, so if a node connects through another IP address (not by "generating IP addresses", that's not a thing, but rather by using proxies or VPNs), it would not be banned.


Here is a link from where you can get some ideas about Cyprus trade of Bitcoins. https://localbitcoins.com/country/CY


Bcoin initial blockchain sync progress isn't saved

I think the configuration you are missing is

memory: false

See the default full node application script here: https://github.com/bcoin-org/bcoin/blob/cec3c3e788834d3e9fc3c0b21bc3e340d573dcfd/bin/node#L31

By default, bcoin objects (like chain and walletDB) run in memory.

So actually I'm curious what is taking up the 10GB in that directory? Could it be data from a previous run with a different configuration? There could be a bug, but just looking at the script you have posted here, I would expect the Full Node to run entirely in memory and therefore start over on each execution.


Is using bitcoin for savings a risky choice?

Buying bitcoins shouldn't be thought of as savings, it's a very high-risk speculative investment. It could go way up in value, or way down.

Luckily, if you want Bitcoin's power of secure storage without exposure to the exchange rate, you can do that too, in theory at least. Use most of your funds to buy X bitcoins, and use the rest as collateral to short-sell X bitcoins. You'd have to pay a bit more for the exchange, pay an interest rate, and trust some of your money with the platform, and there aren't currently very good margin trading platforms, but it can be done and might be worth it if you're sufficiently averse to the traditional alternatives.


It is difficult to cancel a Bitcoin transaction after it's been sent, and it cannot be done by the recipient, only by the sender.  If the transaction has been confirmed, cancellation becomes impossible.

However, the funds are not lost.  They will be waiting in the address until you claim them.  You can either eventually finish installing and syncing Bitcoin Core (possibly on another computer), or you can import your wallet.dat file into some other software with lower resource requirements, and you will be able to spend your funds then.


The signature also signs the Pubkey Script and Amount (which together would represent what you reference as "output of Tx").
Quoting the Transaction section of the Developer's guide:

Bob’s secp256k1 signature doesn’t just prove Bob controls his private
key; it also makes the non-signature-script parts of his transaction
tamper-proof so Bob can safely broadcast them over the peer-to-peer
network.

Image Source: Developer Guide: Transactions

As illustrated in the figure above, the data Bob signs includes the
txid and output index of the previous transaction, the previous
output’s pubkey script, the pubkey script Bob creates which will let
the next recipient spend this transaction’s output, and the amount of
satoshis to spend to the next recipient. In essence, the entire
transaction is signed except for any signature scripts, which hold the
full public keys and secp256k1 signatures.


Can we report a fraudster by their bitcoin wallet address?

Nope, sorry, there's no way to do this.  The whole point of Bitcoin is it's censorship resistant, so there's no way to publicly blacklist addresses (although some exchanges have been known to spy on your incoming and outgoing transactions, such as Coinbase which have a TOS that prohibits it, and will threaten to close an account if you send transactions straight to/from a gambling site: https://www.coinbase.com/legal/user_agreement?locale=en).

Plus the user is probably using a new address each time, since you can generate as many as you like there's no need to reuse it.


How can I get all the Bitcoin transactions data since its inception?

This is called the Blockchain.  You can access it yourself if you use a client like the reference client, Bitcoin-QT.  By reference, I mean that Bitcoin-QT downloads it to your disk... you have to write a program to access past transations, because Bitcoin-QT doesn't allow you to search past transactions other than your own.

Another way to access the blockchain is to use a web site like Blockchain.info. You can either use the web pages to review the blockchain, or use some of their APIs.


How can I figure out where I created my Bitcoin wallet?

A bitcoin private key is a random 256 bit number. A bitcoin address is deterministically derived from that private key. Everyone uses the same procedure to do so. Therefore, it is impossible to figure out where you created the wallet based one a bitcoin address.

Your browser history, however, might lead you to the correct website. You can limit the websites to check to those you visited when you suspect to have created the wallet, therefore narrowing down the places to search.

Since you don't know the website and probably need credentials to access you wallet there, you probably saved the password in your browser. Since the number of saved passwords probably is much smaller than the number of websites you visited, searching your saved passwords might be the best way to go. Every modern browser should be able to show them to you, along with the website they belong to.


Signature: encoding a message - transaction to a point of curve y^2=x^3+7 and Bitcoin Core

To sign a transaction (message) in Bitcoin system, you need to encode the message to a point of the curve y^2=x^3+7

Perhaps you're thinking of ElGamal encryption, whereby you do need to select a point on the curve which represents your plaintext.

However for signing, Bitcoin uses ECDSA, and this has no such requirement.

If you're interested, the code which implements ECDSA signing is in secp256k1_ecdsa_sig_sign(). For example, this is the code which implements step 6 from the Wikipedia link above.


Take a look at this website, They may be what you're looking for.


How do we distinguish between BTC and BCH in an address?

By looking at the post-fork BTC and BCH blockchain transaction-journals independently.

What does this "the address also contains" really mean?

They are saying that in both the BTC and BCH blockchain transaction-journals there were unspent transaction outputs associated with an address that existed in both.

Do they only mean that the transactions are committed before BCH, BTG, and BSV forks happened?

That seems most likely.
Incidentally, since many addresses are created deterministically, I suspect it is possible that re-use of the same keys in both BTC and BCH wallets would cause either to generate the same sequence of addresses post-fork. I am not familiar with BCH and don't know if they continued to use the same HD algorithm, it seems possible.


What happens to the bitcoin mining if the device changes?

Will this device change make it impossible for me to exchange the earned bitcoins to dollar

No, it will make no difference whatsoever to your ability to exchange earned bitcoins to dollars.
However this is because all websites offering Bitcoin mining with mobile phones or laptops are scams which have no intention of ever giving you the Bitcoins they have tricked you into thinking you have earned.
Criminals don't care what changes of computer their victims make.
They might use it as a convenient excuse to blame you for not being able to give you your "earnings" but they'd have easily invented some other excuse if you hadn't made any change.

As others have noted

The difficulty of mining Bitcoin has increased hugely year on year.
It became infeasible to mine Bitcoin on laptops many many years ago. You now need nearly-free electricity and the equivalent power of tens or hundreds of thousands of laptops to have any chance of profit.
It has never been possible to mine Bitcoins on smartphones.


All of the information in the screenshot is publicly available.
And no, they won't be useful for recovering your Bitcoin.
If you used Electrum, you either need the wallet, the recovery phrase(seeds) or the private key(s) to recover you Bitcoins. Note that when you first create your wallet, you are instructed to write down the seed (12 or 13 dictionary words), so if you followed the instructions and still have the seed you can recover the wallet.


How to: Check whether or not transaction inputs have been previously spent

Any node (not just a miner) can check whether a transaction's inputs have been previously spent by looking through the entire blockchain to see if any transaction has spent that input. There is no correct or incorrect way to do this; not all nodes have to do this in the same way.

The common way to do this is to trust yourself (as a node) to have verified the blockchain correctly in the past. What Bitcoin Core (and other software that follow Bitcoin Core's methods) does is it maintains a separate database that contains all of the unspent transaction outputs. So if the previous outputs that a transaction's inputs references are not in this database, then the node declares the transaction invalid. It assumes that its database is correct because it built that database.

There is nothing that forces miners to do anything. A miner could create an invalid block that contains an invalid transaction (e.g. one that spends from a non-existent output). However all nodes (not just miners) verify that blocks and transactions are valid. So the Bitcoin network will reject any invalid blocks and thus the miner will not actually get his reward for his work. This incentivizes miners to verify block and transactions, but they aren't forced to.


How do I get bitcoin price without any external source?

The bitcoin price is determined by a free market of buyers and sellers. There is no way to calculate the price on your own without an external source. I suppose the only exception to this would be if you ran your own bitcoin exchange and you had enough users and volume to produce a fair market price.


Syncing bitcoin node with multiple cores

What makes you think that this isn't implemented?

Block download is already multithreaded and blocks are downloaded out of order. Everything that can be verified in a block without requiring other blocks (such as the PoW matching the PoW stated in the block header, merkle root, etc.) are verified when the block is received. This all happens in separate threads.

But the bulk of verification is checking that the transactions within the blocks are valid. This cannot be done without having verified all of the blocks previous to the one being verified, so this is unfortunately a serial operation that cannot be parallelized.

The crux of the issue has to do with the UTXO set. Suppose block 2 has a transaction that spends an output created in a transaction that is in block 1. If you receive block 2 and start verifying transactions before you have block 1, then you will be unable to verify the transaction whose parent(s) are in block 1. Thus you must wait for block 1 to be received and verified before you can verify block 2.

Of course you can still check the other things in block 2 and write it to disk first, then proceed to download more blocks. These just need to be queued for the actual transaction verification.

The transaction verification involves adding and removing items from the UTXO database. This database needs to be written to disk which means that there will be a lot of disk I/O which is generally slow. The database is cached in memory but is flushed to disk when the in memory cache becomes full. You can make this faster by increasing this cache. In your bitcoin.conf, add a line dbcache=<n> where <n> is the amount of RAM in MiB that you want to dedicate to the cache.

The default dbcache is 450 MiB, so setting a dbcache value larger than 450 will speed up syncing as more of the database is cached and thus less disk I/O is needed. A dbcache of 8000 is large enough that the entire database will fit in memory and thus only be written to disk once. If you have enough RAM for this, then setting dbcache=8000 will allow for the fastest sync time.


How do transaction costs compare between Bech32 addresses and legacy Bitcoin addresses?

Transfer from Legacy ⟶ SegWit: pay full fee (doesn't benefit from SegWit discount)
Transfer from SegWit  ⟶ Legacy or SegWit: discounted.

Note: SegWit addresses can be Bech32 bc1... or they can be nested in a legacy P2SH 3... address which are backwards-compatible (although less efficient). Many exchanges, wallets support the legacy "nested" form only.


Is it possible to set up electrum server for other alternative currencies

In theory, sure. All of these coins are just code at the end of the day, and the electrum server could be modified to handle whatever currencies they wanted to.

In practice however, adding additional coin support to a server is a big deal, and unless you are trying to solve a problem to which there is no other good solution, probably not worth the effort.


Bitcoin block headers serve as the timestamp system for bitcoin. Whichever miner finds the next block includes their systems timestamp and the network either agrees it is valid or throws it out for being outside their margin of acceptance.

Bitcoin verifies the time with a margin of nTimeOffset, which is set by bitcoin asking other nodes what time they think it is and taking the median. You can find this code by looking at AddTimeData in util.cpp, found here: https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp

It should also be noted that some miners, principally ASICs, do so much hashing that they actually push their timestamps a few seconds into the future using rolltime to get extra work sets: https://en.bitcoin.it/wiki/Getwork#rollntime


Why is it impossible to modify a transaction in the blockchain?

Each block in the blockchain commits to all of the transactions in the block and the order that they are in. It does this by including the hash of all of the transactions in the block header, which is then part of the data that is hashed for the proof of work.

Modifying a transaction in a block will change the hash of all of the transactions which ultimately changes the hash of the block header. This will likely make the block header's hash have an invalid proof of work. Thus in order to modify the transaction, you would have to redo the block's proof of work, i.e. remine the block.

Furthermore, the block header includes the hash of the previous block. So if you want to change a transaction, you will need to also remine all of the blocks following the block which contains the transaction you modified. Lastly, your set of modified blocks are actually a blockchain fork. In order to get it to be accepted by the rest of the network, your fork will need to have more cumulative work than the current blockchain, which effectively means that your fork needs to be longer than the current blockchain.

Overall, modifying transactions already in the blockchain requires remining blocks, and after a transaction already has a few confirmations, doing this requires immense amounts of computing power. So much computing power is required that modifying blocks is effectively impossible to do.


Add bitcoin payments to java app using BitcoinJ

Not really for BitcoinJ, but a general approach.
You generate new address for every user you register. Store it in your DB with the userID for future reference.
Create a getAPI taking a String input. use your API endpoint and open the Bitcoin.conf file.
walletnotify=curl <your API>

If you want to have confirmation logic as well, you may need one more getAPI, and get the endpoint. then update your bitcoin.conf file again with following:
blocknotify=curl <your Block API>

Now when user makes the deposit to the address you generated, Bitcoin node will notify your app by calling the wallet notify API. You get the transaction hash. Use that txHash and make a Post call to your daemon with RPc command:
getTransaction <txHash>

Now you'll have entire transaction object to find which user has made the deposit.
Free tip: Bitcoin node calls walletnotify two times:

When a transaction is added to the chain.
When that transaction receives first confirmation.

If you don't want more than one confirmation, then blockNotify is not needed.
If you want a practical example, you can check my Github repo, where I have done it. It's not based on BitcoinJ but the logic remains the same:
https://github.com/kunalbarchha/generic-wrapper-for-bitcoinforks


Oops! Noob mistake.

I thought that testnet and regtest had different version prefixes (not compatible) but they are (the bitcoin wiki and bitcoin developers page doesn't clarify this, though). So I went into a npm package that added dogecoin and litecoin testnets compatibility with bitcoinjs-lib (it's called bitcoinjs-testnets).

But the solution in the second Github link that I posted works.

Here I repost the text:

  Just want to give some feedback that may help new users in the future.
  I lost a lot of time debugging an issue that is probably extremely
  obvious to some, but it was not directly obvious to me.

var bitcoin = require("bitcoinjs-lib");
var keyPair = bitcoin.ECPair.fromWIF("mywif", bitcoin.networks.testnet);
var txb = new bitcoin.TransactionBuilder(); txb.addOutput("myaddress", satoshis);  // <---- this will fail with "has no matching Script"

  Because of the error message I came to the conclusion that I was doing
  something fundamentally wrong creating the transaction. In the end, it
  turns out I just needed

var txb = new bitcoin.TransactionBuilder(bitcoin.networks.testnet);

  Feel free to close this, just wanted to share my experience

I wish my noob experience has helped you! (pardon for my english).


What's "walletconflicts" in listtransactions method output

This is new. It is a field, which contains txids which hold the same data as the original transaction (but has different txids).

See ID-malleation bug


Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transactions to get more transactions fees (assuming they would hit regularly the block size limit).

Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.

BTW, notice that the virtual balance your client shows for each of your “accounts” may not reflect the real repartition as seen by the network for each associated address. (It costs nothing to move virtual amount from one account to the other, but it will also not change the way transactions will be build later by the client).


How can I make MultiBit go one year back and then replay the blockchain?

When you import private keys, you specify a replay date for each private key. This should be before the earliest transaction involving that address. In your case, it appears that this is not the case. (Or maybe you just need to reset again - their site says it might take up to 3 resets for the balance to be corrected.)

You should reimport your private key with the correct date specified to have the balance appear. Note that having your private key(s) in plaintext on your hard drive makes them an easier target for attackers. To be most secure, you should consider those keys compromised afterwards: securely delete the file when you're done with it, and transfer the coins to a new address and avoid using those old addresses again.

Another way of transferring the balance is to send it from your out-of-date Bitcoin-QT wallet to an address generated by MultiBit. I'm not sure if that's complicated, the wiki makes it appear simple.


What are the major technical differences between Bitcoin and Bitcoin Cash?

Bitcoin

Has SegWit and it's benefits and costs:

Code complexity (of acceptable amount)

Witness data is discounted in SegWit transactions, somewhat rectifying the fact that outputs are cheaper to create than to spend.

3rd person malleability fix for SegWit transactions

RBF transactions (optional, destroys 0-conf)

Compact Blocks

Ability to soft-forks to introduce new opcodes for SegWit transactions.

Quadratic hashing fix for SegWit transactions

Bech32 address format bc1... for SegWit transactions.

More secure P2SH addresses is Bech32 is used (no 160-bit hash function)

Signature covers value for SegWit transactions (useful for hardware wallets)

A longer list can be found here
Bitcoin Cash

Larger blocksize cap

Half-yearly hardfork (so lots of work for developers)

Obligatory quadratic-hashing solution (based on Bitcoin's segwit sighash algorithm) (In Bitcoin, it's opt-in, because SegWit is, hence Bitcoin doesn't solve the attack vector)

Signature covers value (useful for hardware wallets) (based on Bitcoin's segwit sighash algorithm)

220 bytes OP_RETURN (No incentive for destructive data publishing methods such as P2SH-wrapped multisig)

CTOR transaction ordering (permuting leaves of a merkle scheme is not allowed for block templates, only one possible order)

OP_CHECKDATASIG (based on a feature in the Elements Alpha project)

OP_: CAT AND OR DIV ...

Custom difficulty adjustment algorithm (This isn't feature. Little coins like BCH need more time-sensitive algorithms while large ones like Bitcoin need more precise ones that work over large time intervals)

Banned 64-byte transactions (Merkle leaf vulnerability resolved)

CashAddr address format (a modified version of the bech32 address format used for segwit addresses in Bitcoin)

Schnorr signatures beginning with 15th of May (using a specification based on a BIP originally proposed for Bitcoin)

Graphene, which is Compact Blocks but much more efficient since CTOR was introduced (it may work on Bitcoin too, this isn't a protocol feature)

And the larger difference is Bitcoin favors off-chain scaling while BCH favors on-chain. It won't matter in the long term, because off-chain protocols such as Lightning will come to BCH anyway while off-chain scaling needs on-chain scaling as well in the long term


Can a 51% attack be detected and dealt with?

Can such attacks be detected? Yes.

What you would see is a chain reorganization that invalidates a large (greater than three) number of previously-accepted blocks. The standard client will actually log this -- you'll see a REORGANIZE in the client's debug.log file. The client doesn't currently log the number of blocks invalidated by the reorganization, but that's a simple enhancement.

Can honest users revert such attacks? Sort of.

If a transaction you care about is in the set of blocks that was invalidated, you can always resubmit that transaction. Unless the sender issued a conflicting transaction as part of a double-spend attack, the transaction will still be valid. (The network will actually do this for you automatically. Miners don't want to miss out on the chance to grab the transaction fees associated with the undone transactions.)

As a longer-term solution, there have been proposals discussed to reject reorganizations that invalidate suspiciously large numbers of blocks such as four or more. The problem with these proposals is that under unusual circumstances (such as if a disaster partitions the Internet for half an hour), the network can permanently split with each side rejecting the other side's block chain as a suspicious reorganization.

Essentially, the client would have to go to a "lockout" mode if this happened and reject all transactions until some mechanism to find the real block chain could be implemented. (It could submit all transactions to both chains and consider only transactions accepted in both as confirmed!) One proposal uses a central authority to pick the real chain. This is an area where there is room for innovation.

One important point to keep in mind though: If the sender is not attempting a double-spend attack, you have nothing to worry about (other than the reduced usefulness of an unstable exchange network). You can submit the transaction to the block chain as many times as you need to until some block containing the transaction finally does win. Only the sender can create a conflicting transaction that would make you unable to get the transaction you care about into the chain.

Update: In fact, you can lose coins even if the sender wasn't attempting a double-spend attack. Suppose A sends B money and then B sends C money, if A successfully uses a double-spend attack to invalidate the transaction that sent the coins to B, the send from B to C can fail (because a conflicting transactions means B will never have the funds to spend) even though B was not attempting a double-spend attack.


what is the best software based solution to secure the private key in Bitcoin

Hm. Rather strange question you ask.

First of all: it depends mostly on the infrastructure you use for your bitcoin-client.

If your OperatingSystem is compromised, you probably can't guarantee security of your privateKey at all.

The Bitcoinclient supports a very strong encryption of the wallet (and ofc the private Key) since like 2 years natively.

I guess if you are paranoid and want extra security, use a VirtualMachine, install some hardened Linux-OS (DebianStable?), there make a TrueCrypt-Container with a hard password and install your Bitcoinclient there.

Ofcourse, as mentioned earlier, you can't be more secure than making an offline-wallet. Remebering your key instead of writing it down could also serve as the absolute security feature. - but i guess you don't want to go that far? :)

i saved my keys in a TrueCryp-container encrypted with sha512 and used a strong password - after this, backup copies of this container wherever you want, so you don't lose it. sha512 is not even crackable for the NSA.


What python code is necessary to convert the integers of a bitcoin public key into the proper hex version thereof?

y = hex(xPublicKey).rstrip("L").lstrip("0x")
z = hex(yPublicKey).rstrip("L").lstrip("0x")
hexpublickey = "04" + y + z


Recovery of possibly corrupted Bitcoin Wallet

Note there are two kinds of encryption for wallets:
Encryption of the wallet itself, and of just the private keys.
If your wallet is very old, it did not support wallet encryption at the time.  Only your private keys are encrypted.
Decrypting your private keys has failed because your passphrase is wrong.  pywallet is just not giving you a good error message.
I wrote a guide to corrupt Bitcoin Wallet recovery which has some other tools you can try.


If you confirm others' transactions, what do you do to earn 25 bitcoins per block?

Just to give some specifics in addition to David Grayson's answer:

At current difficulty levels, mining a block requires computing an average of

  29,973,900,941,385,007,104

hash operations.  An ordinary computer can perform perhaps 10,000,000 such operations per second.  At that rate, such a computer would take about 95,046 years to mine one block, on average.  If the computer draws 100 watts of electricity, it would use 3,469,201 kilowatt-hours of electricity over that time.  Electrity prices are somewhere around US $0.10 per kWh, so that would cost US $346,920 in electricity alone - much more than the $12,325 of the block reward.

For obvious reasons, most miners today don't use ordinary computers, but rather specialized ASIC hardware that is considerably more efficient (and more expensive) than an ordinary computer.


I did the same exercise on my OSX system, and this is my result:

$ openssl version
OpenSSL 1.0.2j  26 Sep 2016

$ openssl ec -in privkey.pem -outform DER|tail -c +8|head -c 32|xxd -p -c 32
read EC key
writing EC key
18e14a7b6a307f426a94f8114701e7c8e774e7f9a47e2c2035db29a206321725

I assume that the PEM key is not in correct format, PEM follows some specific rules. There are several discussions also here in bitcoin.SE

My privkey.pem looks like this:

$ cat privkey.pem
-----BEGIN EC PRIVATE KEY-----
MFQCAQEEIBjhSntqMH9CapT4EUcB58jndOf5pH4sIDXbKaIGMhcloAcGBSuBBAAK
oSQDIgACUIY61kqHroov6Dwa8ahAPLU/U+SG2FEdrYoEiH5bI1I=
-----END EC PRIVATE KEY-----

This is a "test" key, note the word "Risc" in the generated bitcoin address from this key. Don't use it for any value, the funds will get lost.
If you have a test key, and really it is a test key, you can share it, and we can have a look at it (and you will then never ever use it again).


If it was between 2010-2011, it must have been MtGox [dead], Britcoin [dead], Bitmarket [dead], Bitstamp [alive], Kraken [alive]. If she's lucky, she used Bitstamp or Kraken.
She stored the BTC on the exchange or did she ever transfer any to a wallet?
If you know the company or individual who owns the domain her email was registered on, I'm sure they'd be willing to register her username (probably would need to add some motivation by way of money).
I don't know of any exchange that would accept giftcards to fund your account, so there must be something in her bank statement or credit card statement to reveal where her funds went.
Also did she use her legal name to register on the exchange?


How will other coins like LiteCoin influence market price of BTC?

New currencies that supply similar features to Bitcoins can increase the effective supply to the extent the coins are interchangeable in the market. Even if the other coin is worth, say, one tenth as much as a Bitcoin, ten of that coin can still be used as a market substitute for one Bitcoin.

Depending on the currency's properties, however, it can also increase the demand for Bitcoins, which can drive the price up. If it brings in new users, new merchants, or even new speculative interest, that can be an upward force.

But I think your question about competition, following the question about market price, just assumes that higher prices are good for currencies. I have to disagree with this for several reasons. First, Bitcoin is still in the early stages. It needs to be adopted as a means of exchange to survive long term. Increase in prices can discourage adoption because high prices can increase the fear of a "bubble burst" leading to a sudden drop. Currency risk drives down adoption.

The value of a Bitcoin can be a good measure of adoption because use as a means of exchange drives up demand which drives up price. But the converse doesn't follow. The absolute price of Bitcoin has no effect on its suitability for use as a means of exchange. If it's worth half as much, you just use twice as much.


if the cap is 21 million bitcoin does this mean that there will be only 21 million transaction?

No, this is not correct.

It is possible to spend tiny fractions of a bitcoin.
Coins can be passed on from person to person (just like any other kind of money).  So the same coins can be involved in many different transactions.

Incidentally, the reward for a valid block hash is currently 25 bitcoins, not 1, though this will decrease over time.  Even after this decreases to 0 (when the total number of bitcoins in circulation is 21 million), it will still be possible to have new transactions as people give each other bitcoins in exchange for goods and services.

There is no practical limit on the number of transactions.


What are the specific problems that Virtual Currency is solving? (in the Banking system, economics, and finance )

Some problems that come to mind with the fiat banking system are:

Transactions are never really "final" (unless you use cash) since banks or credit cards can "charge back" or "reverse" them at any future time simply because they take the side of your counter-party, often without even listening to your side
The justice system can take your money at any time.  If a court decides that your money may have been ill-gotten or that you owe someone else money (due to a lawsuit or divorce for example) they can unilaterally take as much as they see fit.
The legislative system can take your money at any time.  If a legislative body determines that it needs your money for some urgent need (such as to pay back national debt, as happened in Cyprus) they can unilaterally take as much as they see fit.
The bank themselves can take your money at any time (for example if they see your business as "risky" or suspect you of making money illegitimately).
The bank can (and virtually always does) limit your ability to access your own money.  They can make up rules about how much of your money you can withdraw in a certain time and question your purposes before allowing you to withdraw large amounts.
The banks, government agencies and potentially hackers have access to your transactions... who paid you, and who you paid and when.
Legislative and executive bodies in the government can change the value of your money at any time by manipulating interest rates and the money supply
Banks and governments can (and virtually always do) limit your ability to move your money across national borders. And even when they allow it, they charge banking and exchange fees, delay your transaction significantly, and subject it to increased scrutiny and record-keeping
Banks and governments can (and do) limit your ability to transact with anyone you want. If there is someone they want to starve of funding they will prevent you from paying them.
Banks allow a "pull" model of transaction.  In other words, not only you but anyone else can initiate a payment out of your account.  As long as the bank believes the transaction to be legitimate they will allow someone else to reach into your account and take your money.


getrawtransaction not working for 0th BTC block transaction

It's a result of a quirk from the original Bitcoin client which has been carried forward to today. Originally, the UTXO database held entire transactions; it was similar to/basically the same as the transaction index that exists now today. However the original Bitcoin client had a bug where it did not include the transaction data of the genesis block. This is because the genesis block was not processed like every new block so it's data never made it into the UTXO database. Because it was never part of the UTXO database, it affects consensus so this bug cannot be fixed without a hard fork.

Fast forward to today and the genesis block is still not processed like other blocks in order to keep UTXO databases consistent so there is not a hard fork. This also means that the transaction in the genesis block won't be part of any databases, including the transaction index, which is why you cannot look up that transaction. Fixing this so that the transaction were added to the transaction index would require significant changes to fix this one special case as the block cannot be processed or it may cause a hard fork.

Instead of trying to query the transaction, you should use getblock using verbosity level 2. This will decode the block even further to give you the transactions decoded instead of just their transaction ids. Since the block itself is known and in the block index, the block can be fetched and decoded so yo ucan get the transaction data that way. In fact, I would recommend that you always use getblock with verbosity 2 so you can get the block data and all of the transaction data decoded with one RPC instead of needing multiple to fetch each transaction in a block.


Bitcoin Testnet Trouble with bitcoin-ruby

Due to a lack of responses here, I cross posted this question on the stackoverflow channel. Here is a link with the answer:

https://stackoverflow.com/questions/31409720/using-bitcoin-ruby-to-make-a-transaction/31420786#31420786


How can I have Bitcoind.exe use the core data from Bitcoin-QT on my D drive. Using Windows 10

There are a few ways to do it one of which is modifying the shortcut as you've mentioned.

The easiest way is to create a bitcoin.conf file in %APPDATA%\Bitcoin. That's the default directory bitcoind will look for a configuration file.

Based on your question you can set the contents of bitcoin.conf to:

datadir=D:\Bitcoin Core data


Can I buy bitcoins with moneygram in Australia?

You can just use one of the bank exchanges such as omnicoins or bitXoin for this function. There are less fees as well.