How was the magic network ID value chosen?

main.cpp carries this comment:

// The message start string is designed to be unlikely to occur in normal data.
// The characters are rarely used upper ascii, not valid as UTF-8, and produce
// a large 4-byte int at any alignment.
unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };


How to restore wallet from wallet words after hard drive crash with no back up?

Since you added the Electrum tag to the question, I'll assume you're using Electrum.

When you first start up Electrum, you get the choice of creating a new seed or creating a wallet from an existing one. At that point you would select to enter your existing seed words, and it should recover your wallet.


Reuse of addresses by a service ("get new address" returning *funded* addresses)

Keep in mind that the marketplace in question may not use bitcoind, and if they do, may not use it in the most sensible way. Some possibilities:

A list of addresses was generated. When it reaches the end of the list, it loops back to the beginning and reuses the old addresses, assuming that nobody should reuse their old one again. (this is a poor design: addresses should not be reused for privacy, and so that in case someone sends to an old address, you know whose is whose)
The addresses were generated with such low entropy that the same addresses were created and used again. (this is a serious security flaw in their setup)

In either case, it's possible that either...

the system records both accounts as owning the address (which is very bad, since you can both spend each other's money), or
only one of the accounts as owning the address. Which is very bad if the one owning it is the old one, since new funds are likely to be sent to the wrong person; or only slightly bad if the one owning it is the new one, since the old account owner may be inactive and should not reuse his old address anyway if he makes another deposit.

Regardless of the details (which you as a user aren't going to know anyway), it would make me very hesitant to use the marketplace, since it points to a dangerously sloppy design.


Short-term capital gains taxes for crypto to crypto trades?

It will depend on the tax laws in your country.

Where I live the tax law treats crypto currencies as an asset and requires that my position be reconciled at the end of each financial year for capital gains calculations.

That's not to say I have to do any buy or sells of each year I just have to determine my paper capital gain or loss for the year in order to include it on my tax return.


Why does the threshold apply to the MUST_SIGNAL phase in revised BIP 8 (lot=true)? Why doesn't it enforce 100 percent signaling?

nickler answered this on IRC.

In a mixed network, the rules can become active, but in two separate chains because lot=true nodes will reject blocks from the lot=false chain which doesn't require 100% signaling.

The MUST_SIGNAL phase (when lot=true) overlaps with the last two weeks (2016 blocks) of the STARTED phase (when lot=false). In the case that the threshold of miners signaling is met (but not 100 percent of miners signaling) during these two weeks you don't want to create a chain split between lot=true and lot=false nodes for no reason. If MUST_SIGNAL enforced 100 percent signaling and there wasn't 100 percent signaling during this period you would get a chain split between lot=true and lot=false nodes.


E-voting is a hard problem. There are three major sub-problems: (with two extras if you use a Bitcoin-based system)

How do you provide a trustworthy computing environment?
How do you distribute voting keys to voters? (Or, how does the government get an accurate list of keys that belong to real voters, with no duplicates?)
How do you prevent denial of service attacks against the network being used to send completed ballots, and the network that announces the results?
(Bitcoin only) Does it scale?
(Bitcoin only) What's the preference of the hashpower majority?

Actually counting the vote is a comparatively simple problem.
Trustworthy Computing Environment
Most people's computers are not very secure. Depending on who you ask, between 30%-48% (1), (2) of computers are infected with some kind of malware.
If there's some kind of malware on a computer, how do you prevent it from altering the vote before it's signed and sent out?
As far as I can tell, the linked whitepaper doesn't address this.
Getting Keys to Voters
I don't think this part is any more difficult than distributing absentee ballots.
You keep a list of voters along with contact information and addresses. If there's a question about whether two people are the same, or whether a person exists, or whether a person is qualified to vote, you use a series of gradually more expensive identity verification methods.
Denial of Service
Some of the people who tamper with an election do so to alter the result. However, some people are satisfied with preventing the election from completing, or calling the results of the election into question. This could be something like BGP hijacking, or a denial of service attack against the DNS servers that introduce new nodes into the network. Or, as a more targeted option, find a list of people who are likely to vote for Candidate A based on what Facebook groups they're a member of, then send a denial of service attack to their home internet connections.
(Bitcoin only) Scale
Let's do some back of the envelope math. You need to count 150 million votes. A bitcoin transaction takes about 200 bytes per vote. Multiply those two numbers. That's 30 GB. Bitcoin has a block size limit of 1-4MB, meaning that a day of blocks can contain 600 MB at most. Even if you make some very optimistic assumptions, it's an order of magnitude too small.
This implies that you need something more efficient than 'broadcast all votes to everybody.'
The whitepaper suggests using simplified payment verification, but since Counterparty rules are not consensus rules, an invalid Counterparty transaction can be included in a block without making that block invalid. Therefore, even if every miner is honest, SPV cannot be trusted.
(Bitcoin only) Hashpower preference
What happens if a majority of hashpower have a preference for who should win the election, and they decide to rig the election in that person's favor?
Well, they can. They can exclude any opposition votes from their blocks, and refuse to build on blocks that contain opposition votes. It's not clear how you could punish them for doing this, or that it's even illegal.
If that's too overt for your tastes, you could exclude opposition votes from blocks you mine, but still build on the longest chain. This doesn't even require a majority of hashpower, but it could still change the final tally.

Things that aren't problems

Brute force attacks
There are certain physical limits about how efficient computers can be. There is also a limited (but very big) amount of energy in the universe. Therefore, there's also a limit on the number of bruteforce attacks you can attempt, which is smaller than the number of keys in a 256 bit keyspace. There's a more detailed version of this argument here.
The bottom line is that you shouldn't worry about brute-force attacks. Instead, worry about attacks which are more efficient than brute-force.


How could we determine that a particular transaction in which block's Merkle tree?

As seen from the example image, we actually could not know that transaction-3 is located under that specific block and leaf-node since a light client only downloads the merkle root

As a light client, you would be given the branch/path of the tree which corresponds to the transaction you wish to know about, not just the merkle root. By giving you the transaction itself, and the branch of the tree, it lets you verify that the transaction was indeed part of that merkle root. Otherwise there is no way to tell, it is not possible to extra transaction IDs from a merkle root without being given the tree of transactions themselves. A merkle root is just a hash, a 'summary' and commitment to the transactions, it doesn't actually contain any information.


Old blockchain info wallet password lost

Due to the way the blockchain.info wallet works, without the password (and the second password if enabled), there's no way for you to recover your funds.

As a last resort, if you remember bits of the password, you can try to use services/software that'll try to bruteforce the wallet ; given the low balance of your addresses, I doubt it's worth it.

Sorry for your loss.


Configuring Windows Bitcoin Core Wallet for use on Tor

Yes, following this guide should be all you need to do.  It sounds like you've already done that.

Alternatively, I've found that it's cheap and easy to set up a TOR wifi access point that you can connect to, and then all network traffic is proxied over TOR.  That way, neither your local computer nor your Bitcoin Core installation need any special configuration.


How would one relay a raw tx double spend to a node that accepts it?

You will have to have custom software that can broadcast the transaction for you. Basically any and all nodes and transaction broadcast services will fully validate the transaction before it is broadcast. One part of that is checking for double spends, so you will need software that does not do this. AFAIK, there is no publicly available software that does that, so you would need to write your own broadcaster.


Satoshi is simply a denomination, not a different currency.

1 BTC is comprised of 100000000 Satoshi, similarly to how 1 dollar is 100 cents.

To convert between them, all you need to do is multiply or divide by 10^8.

For example, 1 BTC is 10^8  * 1 Satoshi. Similarly, 10000 Satoshi is equivalent to 10000/10^8, or 0.0001 BTC.


Does the version prefix of an address force the type of transactions the address may treat?

Since addresses are only human abstractions and do not actually exist on the network, no, addresses do not force the type of transaction that you can create with the data provided in an address. There would be no way to enforce that. However creating a transaction that does not use the type that the address specifies is a good way to lose funds because the way to spend those outputs are different.

So yes, you can take a P2SH address and create a transaction with a P2PKH output that has the same data that the P2SH address provided. But the person who controls that P2SH address is not going to be able to spend the coins from the P2PKH output since the requirements for spending will be different.


Who proposed the XBT ticker for Bitcoin and why is it used over the more logical XBC ticker?

XBT is used because the ISO 4217 (the standard for currency codes) alphabetic code XBC is already in use.  It stands for the European Unit of Account.

Here's the Official table of ISO 4217 codes

The X indicates it's not a national currency, but rather a supranational currency (like the East Caribbean Dollar, XCD) or something else that isn't quite a currency, like IMF special drawing rights (XDR) or precious metals (XAU is gold, XAG is silver, etc.) for which exchange rates are of interest.

X is used for this because ISO 3166, the standard for country codes, never uses X as the first letter and the currency code is the 2 letter code and usually the first letter of the currency name.  For example, JP is the code for Japan, so the code for the Yen is JPY.  An exception example is the Mexican Peso, code MXN.  MX is the code for Mexico, and the N stands for New Peso.


Does mining require downloading the transaction history

You can mine them, as long as you're in a pool, where your earnings (awarded as shares of the blocks you help solve) will go to your pool wallet online until you pull them out into your local wallet.

Generally speaking you want your coins in your local wallet so that if a pool goes down or is compromised in some way, you don't lose your hard-earned coin.

So start downloading the blockchain with your wallet, but while you do so you may also begin mining.


Bitcoin-Qt - backing up unencrypted wallet then encrypting it

Besides storing your current private keys, bitcoin wallet file also contains some pool of unused private keys. When encrypting wallet, this pool is flushed.

If you make some transaction using new (encrypted) wallet then change is sent to one of addresses from the pool, which is not present in old (unencrypted) wallet.

For example, you had 1BTC incoming transaction and spend 0.1BTC, then remaining 0.9BTC will be send to a change address. Then old (unencrypted) wallet will not be able to use this 0.9BTC, and they will be lost. But if you haven't done any transactions involving your coins, the old wallet will work.


If you are on MacOS or Linux use

curl https://getaddr.bitnodes.io/api/v1/nodes/SERVER-ADDRESS/

in Terminal or iTerm2

e.g.

curl https://getaddr.bitnodes.io/api/v1/nodes/107.3.158.6-8333/

will return to you

{"detail": "Not found"}

because it's not a running node address and port

and

curl https://getaddr.bitnodes.io/api/v1/nodes/80.56.212.9-8333/

will return to you

{"status": "UP", "data": [70002, "/Satoshi:0.10.0/", 1431732528, 1, 356844, "f212009.upc-f.chello.nl", null, "NL", 52.3667, 4.9, "Europe/Amsterdam", "AS6830", "Liberty Global Operations B.V."], "bitcoin_address": "", "url": "", "verified": false}r


The usual interpretation of "hash rate" is the number of distinct block headers that can be tried per second.  So this should include the time needed to:

increment nonce value
increment extraNonce or other coinbase parameters and recalculate Merkle root, when needed (once in every 2^32 attempts)
compute two rounds of sha256
compare the resulting hash value to the target.

Of course the two rounds of sha256 are the slowest part of this process, by far.

As Raghav Sood says, there's no way to know if any particular vendor is actually following this interpretation, but it's so widely used that I'd regard anything significantly different as fraudulent.


I've lost my MultiBit data, is there a way to access my wallet?

I'm sorry to say this, but your bitcoin is gone. Without your hard drive, you don't have access to the private keys. You may know the password to decrypt them, but what use is a password without a username?

The best option will be to try and go to a professional data recovery service.

Rule of thumb - Always make backups.


try use abandontransaction "Your transaction ID here" and then restart it with -rescan flag

and then add your transaction fees higher (NOTE: ONLY WORKS IF TRANSACTION IS NOT IN THE BLOCKCHAIN)


How do I use Vanitygen on Fedora 20? (openssl restrictions)

First, you need to compile OpenSSL from the sources. I assume that you've compiled it as it is described in the Bitmessage Forum. That way, OpenSSL including elliptic curves support is installed in /opt/openssl-version. As for the Heartbleed bug that has recently been published, please use the very latest stable version of OpenSSL.

Following this description, I will now assume that OpenSSL including elliptic curve support has been installed unter /opt/openssl-1.0.1g

Now coming to vanitygen: Download the zip file and extract it to your hard drive. Then modify the Makefile: At the very top of that file add the following line:

export LD_RUN_PATH=/opt/openssl-1.0.1g/lib

After that, go to the line where CPFLAGS is set. Modify it, so that it looks as follows:

CFLAGS=-ggdb -O3 -Wall -L/opt/openssl-1.0.1g/lib

Basically, the line is unmodified, except for the library path to the custom OpenSSL library, which has been appended.

That's it! Now you can compile vanitygen in Fedora as well:

make
./vanitygen 1TEST


How can we prevent distortion of the bitcoin exchange rate?

There is no single price for a Bitcoin.  There are prices at various exchange markets at any point in time.

Since some exchanges have no requirement that every account has identity verified then there is no way for the exchange to know an account is controlled by another party.

Today's exchanges have no mechnism to prevent what you describe.


If I sell something for bitcoin can I then use the bitcoin I receive to buy something else?

I think the confusion is around the phrase "a single bitcoin". A dollar bill is a thing, you can move it around and it changes ownership, but it is still the same dollar bill.

You might be imagining a bitcoin as a "virtual thing", like a computer file, which you can also move around. Sending the file to someone is analogous to giving them the dollar bill.

The problem is, computer files don't move; they are copied. Even when you tell a computer to move a file from one disk to another, it is simply making a copy and then deleting the original. When you give someone a dollar bill, you don't have it any more. You can't really give someone a computer file, because you simply both have copies.

If a digital currency were implemented this way, you could simply keep giving copies of the same computer file to everyone you paid, and you would basically have an infinite supply of money. That is what people are talking about when they refer to double-spending. The idea of using the same money twice.

So, bitcoin can't be a simple as a computer file. How does spending work?

Imagine a world where there are no dollar bills and coins. Instead, all transactions are performed by credit and debit cards and similar things. In that case, when you spend $1 at a 7-Eleven, you theoretically give them a dollar, except there is no physical thing to move. In reality, your bank and 7-Eleven's bank simply agree to add a transaction to each of their ledgers, saying you transferred $1 from your account to theirs.

In other words, what's actually being passed around isn't "virtual money", but records of transactions instead.

Spending a bitcoin is very much like this: you create a transaction that says you are transferring X BTC from your account to someone else's. That is published to the network and becomes part of the transaction record and then "everyone" knows your wallet has X fewer BTC and the other person as X more BTC.

There is a lot of complexity in how that publishing process works, how it guards against fraudulent transactions, how it works in a decentralized fashion, etc. There are a lot of places to read about how it all works, including this site.

So, if you have 10 BTC and receive 1 BTC, then you turn around and spend 1 BTC, did you spend the BTC you just received? Or one of the other ten? That's a question for philosophers, to be honest.


How do i find my private keys in my blockchain.info wallet?

Please follow the below steps:

Go to settings, then click addresses as shown below:

Click on more options aside your address whose private key you require as shown below:

In 'More Options' you will find "Private Key", please click it:

They will show you a warning as below, please click continue:

You can see your private key for the corresponding wallet address:

Hope this helps you!


Better or worse to mine multiple workers on one machine?

You ought to test the setup on the machine you will be using. Generally the mining software should efficiently use the entire GPU, but it might happen that it will not and actually running two instances at the same time will allow you to tap into more computing power. But again, check your speed while running one or more instances and see which one gives you more total speed.


if it would be possible.

no. this would be wasting energy for heating the room

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


Is pruning transaction history implemented in Satoshi's bitcoin client?

Since Bitcoin Core v0.8.0, the validation database ("chainstate" or "UTXO set", or "account balance sheet") is separated from the blockchain. When a new block comes in, its effects (removing spent inputs, and adding outputs) are applied to the database. This means blocks are still downloaded and verified like before, but they aren't used for validation anymore afterwards. Blocks are still stored on disk in order to send them to other nodes that are synchronizing, or to rescan for old transactions.

Since Bitcoin Core v0.11.0, it is also possible to run in a true pruned mode, where the blocks on disk are actually deleted after a while. Since v0.12 it is possible to use the wallet while running in pruning mode. Since v0.14 it is possible to manually prune (by issuing an RPC command rather than have the application decide).

Note that neither of these mechanisms rely on the mechanism described in the Bitcoin whitepaper.


How do you invert an ECDSA multiplication to get the generator?

k is just a scalar, modulo the order of the elliptic curve group.

Q = k*P

thus:

(1/k)*Q = (1/k)*k*P

thus:

(1/k)*Q = P

You find P by multiplying Q with the multiplication inverse of k modulo the curve order.


Does blockchain.info backup wallet include also the next addresses

No, it doesn't. At least not from what can be seen in the "Export Unencrypted" option and I doubt that it would be any different using the encrypted option.


Bitcoind JSON/RPC extremely slow under load

Bitcoind can be quite memory hungry and bandwidth hungry. If you're swapping a lot, definitely add more memory.

You may also consider using an external API like:

http://dev.blockcypher.com/#blockchain-api

Bitcoind itself is actually quite hard to scale out.


How does Mt.Gox calculate high and low price?

The High Price is the lowest sell order that is on the exchange. Conversely, the Low Price is the highest buy order on the exchange.

However, the Last Price is calculated differently. It looks at what the price was the last several times that bitcoins changed hands.

If Last Price is higher than High Price, or lower than Low Price, that is indicative of one of two things:

Someone is trying to manipulate the last price by trading bitcoins absurdly high or low.
The market has moved since the last trade.


Bitcoin not received from Coinmama to Blockchain Wallet

Depending on amount of bitcoin you sent and fee you opted to pay will determine lenght of time for transaction. Network very busy and sets large transactions and people who pay the higher fees as priority.  It could take a little while. You can check status of transaction by checking blockchain. A few sites allow you to do this using your bitcoin address.


What is the difference between ledger_hash and ledger_index in Ripple?

The ledger_index is the 256-bit index of a particular entry in the ledger. The ledger's state tree is a hash tree of index/value pairs. Each index is a 256-bit hash of some kind of locator. If the entry is, say, an account root node, the index is a hash of the 160-bit account ID. If the entry is, say, a ripple balance node, the index is a hash of the two accounts the balance is between and the currency identifier.

The ledger_hash is the 256-bit hash of the ledger header, which effectively acts as a hash of the entire ledger.


What is the different between full-index client to full node?

"Full-index client" is a term really coined by the author. I've never heard of it in the Bitcoin community. After reading the section in the book, it seems that a full-index client is just a client that holds all the data in the blockchain but is not necessarily a full node. To be a full node you must adhere with all of the bitcoin protocol. A full-index client might not adhere with the entire bitcoin protocol, but would still have the entire blockchain. Full-index simply means "holds all the data", but it might not be a full node. At least that's my interpretation.

To run a full node you must download Bitcoin Core, which is the only supported "full node" I am aware of.


Why was Armory and Blockchain wallet removed from bitcoin.org?

Blockchain.info has suffered from numerous security vulnerabilities, some of which are discussed here:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/663

Wallet listing criteria can be founds here:

https://github.com/bitcoin-dot-org/bitcoin.org#wallets

The reasons for Armory removal are explained here:

"Armory is no longer developed by ATI. Its website, bitcoinarmory.com, is down and is no longer Armory's website. The source code is now maintained by goatpig."

https://github.com/bitcoin-dot-org/bitcoin.org/pull/1235

A new pull request to bring it back is now open:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/1301

the resolution timetable remains unclear:

"goatpig commented 5 days ago

@ABISprotocol I don't control bitcoinarmory.com, that belongs to ATI. Their current policy (I believe) with that domain is to offer binaries for the code they fully own, i.e. 0.93.x versions of Armory.

You could say the current state of affairs is that ATI tolerates my fork (and me using their trademark), but have yet to make a definitive move in either embracing it or opposing it (in which case I'd have to rebrand)."


Why should I care about my transactions ever reaching the blockchain if I can spend them while unconfirmed?

The flaw in your thinking is that you assume your transactions will be confirmed. That is not the case. There is no guarantee that a transaction will ever be confirmed, and in fact, if the fee is too low, it is almost guaranteed that the transaction will never confirm.
You should care because the person you are sending Bitcoin to cares that it confirms. You should care because you won't receive what you are paying for until your transaction confirms. Most merchants will not consider the payment complete until at least one confirmation. If they do not consider the payment complete, you aren't going to be receiving any good or service that you have paid for.
Merchants (and other recipients) care about transactions confirming because it guarantees that the Bitcoin has actually been transferred. While a transaction is unconfirmed, it could be double spent and a different transaction that uses the same inputs and sends the Bitcoin elsewhere could be confirmed. If they accept the payment, provide the goods or service, and then find out that the transaction has been double spent, then they have both not made any money and lost the value of whatever has been provided to you. So receivers almost always wait for confirmations before considering a payment to be complete.


How to get crypto currency wallet balances

Do I need to set up bitcoind, litecoind, neo equivalent, and all of the rest?

You don't have to; you can use different APIs for different coins. But not all coins will have a service that offers that, so for those you will need to run your own node software.

  I'm surprised I haven't been able to find a single unified api provider

You've answered this yourself:

  That sounds like a lot of work and A LOT of server space / resources?

It's simply too expensive for someone to do that.


The bitcoin wiki OP_CHECKSIG page describes the behaviour of SIGHASH_NONE like this:

  The output of txCopy is set to a vector of zero size.

  All other inputs aside from the current input in txCopy have their
  nSequence index set to zero

  Think of this as "sign none of the outputs-- I don't care where the
  bitcoins go."

The contracts page also talks about SIGHASH_NONE:

  SIGHASH_NONE: The outputs are not signed and can be anything. Use this
  to indicate "I agree to put my money in, as long as everyone puts
  their money in, but I don't care what's done with the output". This
  mode allows others to update the transaction by changing their inputs
  sequence numbers.

If I sign a transaction where all the inputs are SIGHASH_NONE then a miner can change the outputs to whatever he likes.  If any of the inputs are SIGHASH_ALL then the miner can't change the outputs.  So a group of people can each sign their own SIGHASH_NONE input to a transaction, send them privately to the coordinator who signs his own SIGHASH_ALL input before publishing the transaction.  That way the individual contributors don't need to know the destination address so long as they trust the coordinator.


How can I pay with Bitcoin on overstock.com o.co?

Only for the USA at the moment according to reddit

  If you go to the checkout page on Overstock you'll see an option to
  pay with Bitcoin!

  -edit- For now it's only available on the U.S. checkout but I hear from reliable sources that they will roll it out to international
  after a bake in period.


How can I tell if bitcoind was compiled with ZeroMQ support?

You should have a file named config.log in your Bitcoin Core working directory. Look in the file for ZMQ related lines. If ZMQ is enabled, you should see things like #define ENABLE_ZMQ 1. If it is not enabled, you should see things like #define ENABLE_ZMQ 0.


How do i parse the zeroMQ messages in java?

Bitcoin Core does not give you strings for the data from ZMQ. It provides the raw bytes of the transactions, blocks, and their hashes. You will need to interpret the received data as byte arrays and handle them appropriately.


Is there an API to create a Dogecoin Wallet?

The block.io service offers DOGE coin wallets and an API.


Bitcoin ECDSA signature in the compact format

What you are looking at is just an implementation detail that you really don't need to worry about. It's just converting from an internal format (which may use different coordinate systems and bit lengths, especially for tests) to the standard output format. Within the library itself, the data in the signature may be easier and more efficient to handle when in other formats or coordinates systems. So the structures that represent that data store the data differently. However when outputting results, it must all be in a standard format, so that's what these conversions do: change from internal representation to a standard output format.

This is done for any of the signature serialization outputs that libsecp256k1 does. The compact format is just the two 256 bit values for R and s concatenated with each other. The first 32 bytes is R, the second is s. For standard compact signatures, that's it. For compact recoverable signatures (which is what you are looking at), there is an additional last byte for the recovery id.


Is the fastest Bitcoin ASIC miner available today still profitable after block halving?

The s7 miner is still a bit profitable (25% profit).
The s9 miner is the fastest and most efficiënt miner i know of and is way more proffitable of course.

edit/explaination:
Hashnest has a percentage monitor of profit/costs. Thats where the s7 number comes from. S9 is way more efficiënt following the specsheet on the antminer website. You can calc your profit over at coinwarz too, there you can edit power costs/usage and even the ROI is calculated there. Take a look i should say (its indication tho)


Lightning: Is it possible to send lightning BTC outside of a lightning state channel?

There is no such thing like 'lightning BTC'. It is the same BTC, either on-chain, or comitted to a lightning channel, which is technically a 2 of 2 multisig transaction. To receive via lightning, a lightning full node or a wallet with lightning receive capability is needed. And correct, you need to open a channel first, which takes one on-chain commit, the the associated waiting time. But it is possible to transfer value at the same time by already assigning a portion of the channel funds to the receiver when setting up the 2 of 2 multisig transaction. All later value transfers inside the channel will be an just update of this transaction, which will be instantaneous. So either way, no need for a second transaction in terms of on-chain transaction. Except for the closure of the channel, if needed - which will another on-chain transaction ( channels can stay open indefinitely, though).


How can I recover the missing end of my private key?

TL;DR:
You don't need to bruteforce anything here (at least almost), and can recover the missing last 7 characters on an average PC at home within less than 1 second using a simple Python script!
In detail:
In your picture there are 7 characters missing at the end of the private key (figured out by comparing with a test-printout using the same HTML file).
Yes, it is correct that this key format is using Base58 alphabet and therefore there are 58 possibilities per character, so for 7 characters you would need to try 58^7 possibilities (which would be about 2 trillions) in theory, but all these considerations are missing an important fact:
When such a private key (the format is called WIF short for Wallet Import Format, see also the reference documentation here) is encoded, at the end (after the actual private key) 4 bytes are added as a checksum. So if these 4 bytes are missing (at the end) you can calculate it from the rest.
Second: in your picture it looks like your private key starts with an L. This indicates that the Bitcoin address is based on a compressed public key. Don't worry, this is a technical detail, but this helps you further:
Private keys for compressed pubkeys have another special byte added after the key (and before the checksum), namely a fixed 0x01 (see also in the reference documenation for WIF).
This means that the last 5 bytes of a WIF encoded private key (starting with L or K) are either static or can be computed from the rest.
So you are very lucky that the last 7 characters are missing (and not the first 7, because then you really would need to bruteforce 2 trillion possibilities).
What to do with this information:
If we apply this knowledge now to base58 we see that only a single character is missing and then we can calculate the rest.
Reasoning: first: a single base58 character carries ~5.85799 = log2(58) bits of information and second: we don't need the last 40 bits (4 bytes checksum + 1 static byte for compressed key are 5 bytes = 40 bits).
So, if only 6 characters would be missing at the end (6 * 5.85799.. = 35.14794) we not need to bruteforce anything, because this would be still less than the 40 bits we don't need.
Conclusion:
As you are missing 7 characters we just need to bruteforce one single character (and this means just 58 attempts, not 2 trillions).
So we just attempt to add one of the 58 characters from the bas58 alphabet. For each attempt we calculate the full base58 string by adding the static compressed key flag byte (0x01) and after that the checksum and simply compare it with the rest of the key you have. If it matches it is a valid candidate.
At the end of these 58 attempts you will end up with 2 or 3 (at most) valid private key candidates, and just need to check these 3 keys, to see which one belongs to your address.
The Reddit user /u/dooglus/ (not me) pointed out exactly this in the first place in his comment on your post and he also added a snippet of Python code which does exactly I've described above.
Don't trust anybody, don't hand out your key to any stranger!
Now take your time, learn what the Python script below does (don't trust me or any strangers) and when you feel safe, copy the Python snippet from /u/dooglus/'s comment, save it in a text-file named complete-wif.py on a safe computer. After that take the computer offline and run the Python script by typing this into a commandline:
python3 complete-wif.py L...-your-private-key-goes-here...yhub
and it will print 2 or 3 completed WIF private keys in less than 1 second.
Appendix:
For reference, I appended the Python script but it's not my work, all credits go to /u/dooglus/. I just can confirm that it does what I described above (but ask others to confirm this and try it with other private keys before you trust it with your real private key):
#!/usr/bin/env python3

import base58, sys

partial = sys.argv[1]

if len(partial) != 45:
    print("partial key should be 45 characters")
    sys.exit(1)

results = {}
for c in '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz':
    wif = base58.b58encode_check(base58.b58decode(partial + c*7)[:33] + b'\x01').decode('ascii')
    if wif[:45] == partial: results[wif] = True

for k in results.keys(): print(k)


How can I control which coins to spend in a transaction?

Currently this is not possible with the standard client, other than making separate wallets. There is a patch for coin selection on github, which was very promising. So this feature may make it into a future version.


I have my public key and my recovery passphrase. How do I get my private key to that address

As long as you have the recovery phrase, you can recover it on whichever software you generated the seeds on.

If you forgot the software or service that generated your seeds then you will have to quickly use the most trusted seed recovery service (such as blockchain.info or electrum) and after you recover the seed, immediately generate a new address or wallet and send all your coin to that address to avoid getting your coin stolen unless you planning to use that most trusted software.

Never have anyone to manually recover for you or use the untrusted source as your coin may immediately get stolen before they give you the key.


Mining is the process of extenting the chain with new blocks containing (or not) new transactions. The block reward and any tx fees for that block goes to the miner, who found  a nonce such that the hash meets that block's difficulty target.
In Bitcoin the difficulty retargets every couple weeks I believe. This means that if more miners start mining, they will indeed cause blocks to be found faster than the 10 minute starget on average, until difficulty retargets, where it will go back to about 10 minutes (and possibly go up or down depending on whther new miners arrive, or existing miners leave).

Due to thus two weeks retargetting, there should be only minimal change to the expected time of the last block reward (accumulation of each two weeks period's drifts).

Last, the number of txes do not influence the number of blocks. The miner does get a bit more due to the tx fees, but whether blocks are full or empty or the the middle, the target is still 10 minutes.


What data is available to Ethereum smart contracts?

I'm not sure if this is actually complete, but the solidity language runtime exposes most of the useful stuff:

https://github.com/ethereum/wiki/wiki/Solidity-Tutorial#block-and-transaction-properties

So basically, only existing state and new data entered as arguments from new signed transactions. This means "real world" data mostly has to come from some kind of oracle mechanism.


Using bitcoind, is it possible to set a specific fee with sendtoaddress?

You cannot set an absolute fee, however you can use the settxfee RPC to set the fee rate for the wallet before you make the transaction. Note that this isn't persisted in the wallet and is only held in memory, so you will need to do it again if you restart Bitcoin Core or reload the wallet.

In the next major release of Bitcoin Core, version 0.21, you will be able to set the fee rate in sendtoaddress itself.


I'm trying to run Bitcoin on a weak computer, which client consumes the least resources?

There is a very useful comparison of the Bitcoin desktop clients here:
http://dre.redmartian.org/compare.htm

In order 'lighter' to 'heavier' there are:

electrum

multibit

bitcoind

armory + bitcoind

If you need the full bitcoind RPC API then only bitcoind will do however. In that case trying/ waiting for v0.8 is probably your best option.


Sendrawtransaction error on Bitcoin Core Version 0.16.0

I encountered the same issue, to resolve I resorted to starting the bitcoind daemon using the following flag:

  -deprecatedrpc=signrawtransaction

I am now looking for a better solution.


Bitcore makes it very easy to do this. Just use the Transaction constructor.

var bitcore = require('bitcore')

var txHexSerialized = "010000000...00000000";
var txDecoded = new bitcore.Transaction(txHexSerialized);


Why are Bitcoin addresses starting with 1s or 1S so rare?

When I read pyramids' answer, I was very skeptical. It didn't really seem right to me that addresses generated from a hash (in this case from a public key) would have anything but a random distribution. To test out the distribution of addresses, I downloaded the dataset linked to in this forum thread and counted up how many times addresses appeared. There are something like 2.4 million real addresses in this dataset, so I figured it would give me a pretty decent sample size. Sure enough, pyramids was right, I ended up with a count something like this:

As it turns out, you are much more likely to see an address where the second character is 2-Q than anything else. After some research, it turns out that the reason why this is the case is fairly subtle, and requires some background on how addresses are generated. The technical details of how an address is generated are here and here, but the tl;dr is this:

Hash your public key first with SHA-256, and then with RIPEMD-160.
Add a version number and checksum to the above.
Convert the bytes of this value from step 2 to an integer.
Convert the number from step 3 to a base 58 encoded string.

NOTE: The stuff below this statement is very heavily edited from what my original answer was. The original answer was based on some personal research I had done and it turns out that I got it wrong. Thanks to @MeniRosenfeld for correcting me in a comment.

Step number 3 above is where the bias towards addresses starting with characters between 2 and Q is introduced. The data that you have after step 2 is 25 bytes long, but because of the version number that is pre-pended is fixed (0x00 for the Main Network), there are only 24 bytes that add to the integer you produce. With 24 bytes of data, you will never get a number big enough to generate an address where the second character is anything greater than Q. If however, those 24 bytes produce an integer that is less than ~2.6896e56 you can actually base58 encode it in 33 characters instead of 34 during step 4. When you have numbers this size, there is room available to have a number that will generate an address where the second character is any of the characters between 2 and z. Therefore, the reason that it is much more rare to get one of these numbers is that there are simply fewer of them. The addresses that have a second character between R and z can only be addresses that are 33 characters long while the others can be any address that is 34 characters long or any of the addresses that are 33 characters that have a second character between 2 and Q. This is skewed even further by the fact that there are 58 times more addresses with 34 characters than 33 due to the additional length.

It should also be noted that because of the way base58 encoding works, every extra empty byte present at the beginning of the data in step 3 ends up as a 1 added to the beginning of the final address. Therefore, the first bin on the graph doesn't fit in with the others because it is where all addresses of length between 32 and 27 ended up.


I have 8 Antminers, is there a way I could change their pool credentials all at the same time like through ssh with a script

Here are the instructions for setting a mining proxy which allows all your miners to connect via the proxy instead of via their own config.  This way you only have to stop then start a single process on the proxy to change pools instead of messing with each miner to do the switch.

Setup mining_proxy.py on a linux machine

pont slush's mining_proxy.py at a pool of your choosing using a bash script file (remember to chmod 755  so you can run the bash script with ./)
setup each pool you want to mine with it's own script (same -sp (port)  for each )
point all your miners at the proxy server with the port you are using
make sure all pools use the same worker names and passwords (since this is setup on the miners)
start your chosen bash script (best to use screen so you can exit the session and leave it running)
miners can be switched by ssh via screen -d -r , then ctrl-c (to kill the proxy), now just run the correct bash script to switch to the next pool.


Sending RPC-JSON Commands to Bitcoin Peers

The RPC interface of most nodes is password protected, so you can't send RPC commands to an arbitrary peer on the network. If you run your own node though, you can set it up with a password and the the RPC protocol to issue commands.


What are some of the proposed ideas to why the Bitcoin dropped to sub $400 in the end of summer 2014?

Some possible reasons I read:

Merchant adoption through payment processors

While merchant adoption is growing, it is currently mostly through payment processors, hardly any merchants keep a significant portion of their bitcoin earnings. With the broader selection of things to spend bitcoins on, more people are shopping with bitcoins, yet, not necessarily replenish their holdings. This creates a downward pressure on the markets.

Retailers first, suppliers lagging behind

And the retailers are right to immediately turn their bitcoin earnings into cash: With the current price downtrend, otherwise they would have lost significant value, more than they could have afforded on their margins. The problem is: Since retailers don't have Bitcoin holdings, I don't think there has been much request for suppliers to accept Bitcoin. – But without suppliers taking Bitcoin, there is no reason for retailers to keep them.

Stocks are doing very well

I've seen it suggested, that some early adopters with large amounts of bitcoins might be diversifying their holdings into other assets. The stock market is doing pretty well, and there were some interesting Initial Public Offerings recently.

Price is set by exchanges, yet, the big amounts are traded on Over-The-Counter markets

The Bitcoin exchanges are too small a market for the big payment processors to offload their earnings. So, instead, they sell huge amounts directly to interested parties. It has been suggested, that some of those interested parties might be using their freshly acquired bitcoins to push down the price on exchanges, in order to buy more bitcoins cheaply.

We are still in the correction after the Mt.Gox hype and crash

Some think that we are still in the correction phase after the Mt.Gox hype, seeking the fair price after it was massively overvalued.

Regulatory stance still unclear in many countries

Some suggest that the Bitlicense proposal in NY could be a precedent for other US states to follow suit. Quite a few followers of Bitcoin seem to think that it would be very inhibiting to the adoption of Bitcoin in the US if that were to happen.

Mining crash

A lot of people invested a lot of money into mining equipment that is now not earning what they expected, or which they didn't even get. There might be some financial pressure on them to market more of their Bitcoin holdings than they wished in order to pay for their upkeep.

Weak Hands and Impatient Enthusiasts

The falling price is shaking out weak hands. People that bought too high and want to cut their losses. Also, some are gambling to buy back in lower. Some (younger?) enthusiasts might be getting disillusioned, because Bitcoin isn't changing the world fast enough.

Volatility is down, damping speculators enthusiasm

Volatility had been decreasing for most of the year, making it less attractive for speculators to invest. Apparently, this has changed this week with new record trading volumes on the Chinese exchanges according to Daniel Mark Harrison on Coindesk.

Just some ideas, most is gossip and AFAIK, I'm sure there are plenty more.


Coins are associated with an address, but they are actually stored in transaction outputs.

Transactions take one (or several) inputs (referencing previous transactions) and sign over the total amount of the inputs to one (or several) outputs.

Usually, these outputs are formed in a way that they can be spend by the owner of a specific address, but other requirements to the signature can be scripted. Anyway, each and every balance is at atomic level made up from these transaction outputs.

The transaction outputs, though, reference the transaction that created them. That means, anyone looking at the blockchain can easily see what transaction sent the money to your address.


error: Authorization failed: Incorrect rpcuser or rpcpassword

In case you changed your /etc/systemd/system/bitcoind.service make sure you run
 sudo systemctl stop bitcoind
 sudo systemctl daemon-reload
 sudo systemctl start bitcoind

to apply the changes.


Keeping track of unique deposit Bitcoin Addresses per user

Just run bitcoind on your server and then connect via API to it, here is the reference:
https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

There are also ready (open source) libs in several languages, which you can integrate in your own apps.

Some examples:

https://github.com/Bit-Wasp/bitcoin-php
https://github.com/Bit-Wasp/bitcoin-lib-php
https://pypi.python.org/pypi/python-bitcoinlib

But your question is too broad to give you a more specific answer, since you have to consider, if you want to hold user funds in one wallet and just identify them by different deposit addresses or a separate wallet with it's own keys for every single user.

In general: If you don't know exactly what you are doing, don't store any private keys on the server, especially if you want to hold someone's funds.


Building from source static bitcoind on Ubuntu

You might ind useful these quote from configure docs

Enabling static libraries for a package which consists of only dynamic modules makes no sense, and the package author would probably have decided to ignore such requests

... `AC_DISABLE_STATIC'
These macros tell libtool to not try and build either shared or static libraries respectively. libtool will always try to build something however, so even if you turn off static library building in 'configure.in', building your package for a target host without shared library support will fallback to building static archives.

In other words, check your code for presence of particular macro in configure.in files across subtree. it may have been decided to prevent making it static.


What would the expected block mining time be if 30% of the total network hashrate disappeared suddenly?

You're trying to do 100% of the work with 70% of the workforce.
The expected block interval is to the target interval of 10 minutes as the total work is to the workforce:

Texp = 10 minutes  × (100% ÷ 70%) = 14.3 minutes

The difficulty reset would get extended by the same factor:

Dreset = 14 days × 100 ÷ 70  = 20 days

The expected block interval would be about 14.3 minutes for twenty days.


The "blob vault" is a very simple encrypted storage system used to store Ripple wallets. Your Ripple wallet stores your annotations, named accounts, and so on. You can create a new wallet with the same secret and get your funds back, so losing your wallet does not mean losing your funds.

The guts consist entirely of about 100 lines of Javascript.


The simplest way to send and receive bitcoins programatically is to run the standard bitcoind client and have your software talk to it via the JSON-RPC interface.  You can give it commands to send coins, check for incoming transactions, and so on.

As for how to schedule transactions to be made at some future time: once you know how to make transactions via RPC, doing it at a scheduled future time is really just a general programming question and not within the scope of this site.  The most obvious approach would be a similar algorithm to Unix's crond(8): have a queue of pending jobs in chronological order, and sleep until it's time to execute the next one.  When a new job is scheduled, insert it at its proper place in the queue, and if it turns out to be first in the queue, recalculate the sleep time.

As for whether and how to use cold storage: that's something you'll have to determine.  Keeping the temporarily held coins in cold storage will reduce the risk of them being stolen by an attacker, but also adds extra costs since you will need a trusted human employee to manually transfer coins back out of cold storage at appropriate intervals.  You'll have to balance that against the risks and potential liabilities of having coins stolen.


So I’m kindve confused I have 4.25 btc in BitPay wallet so what’s the difference between a bitcoin worth 33k

Bitpay is likely holding this bitcoin for you, so you legally own it, but it Is controlled by a custodian. The price of Bitcoin is simply the price you can currently sell that bitcoin for on the market.
If you want to fully own and custody your bitcoin, as you should once you're ready, you should withdraw the bitcoin to a personal wallet like Wasabi or Electrum, so that you no longer have to trust BitPay.


Extracting information from utxo for offline processing

Blocks and transactions have very simple structure. It is very easy to parse them in any language. This is a piece of my code (it definetely works). You may write something similar

#include <QTimer>
#include <QFile>

#include "BlockChain.h"
#include "Util.h"
#include "Chainer.h"
#include "Target.h"

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


Are DAG-based crypto currencies as secure as proof-of-work based blockchains?

You need to prove that the witness Selection process is random and independent. Alice can double-spent if she has control over the witness and the network.
Let assume Alice can double-spent, in bitcoin one can wait for 6 confirmations to rule out most of the double-spent. E.g. Seller only sends out the goods after 6 confirmation. How can you achieve this in DAG? since the account is only updated by its' own transaction. On top of that, the graph DAG is very complex compared to bitcoins' link-listed blockchain.
DOuble-spent transactions may get buried by other transactions.


Backing up my bitcoin wallet - is wallet.dat all I care about?

Yes.
Yes.
No. Note that that the software's encryption encrypts only the private keys, not transaction and address book information, so to protect your privacy you may want to add encrypting the file itself.


Your Bitcoin address and your private key are not the same.

The private key is a random number. You keep that number a secret, and only having it allows you to spend Bitcoins. It is used to sign transactions.

From the private key you derive a public key. It is used to show that you are using the correct private key. It is used to verify transaction signatures.

From the public key you can derive the Bitcoin address, which is a convenient way of encoding the public key. It is more compact, comes with error detection, and so forth. It is used to let people know where to send their Bitcoins to when sending you money.

From a private key you can derive the public key. From the public key - the Bitcoin address, but in neither of those cases can you do it in reverse. If you have lost your private key, your money is lost forever.

However, from what I can see your address has been successfully used for withdrawals, and its balance is currently zero. If you have gotten it from blockchain.info eWallet, you probably should contact the owner of the site with your issues. In Bitcoin world, it is very hard to prove that you own an address without having a private key.


Why are some transactions found on some chain explorers but not on others?

Each node on the network has its own mempool. While they are filled with similar transactions, each may have a different size limit or perhaps even custom rules which transactions to retain.

In this particular case you can see (figure 1) that there is a (U) shown in both inputs of the transaction. The (U) means that the inputs are created by a transaction that is still unconfirmed.

In fact, when you look at the address that the two inputs were spent to before (figure 2), you'll see that both were created in transactions that only paid 4.4 satoshis per byte whereas the transaction you linked pays 65 satoshis per byte.

I would surmise that the first two transactions that created the inputs might have not been relayed to or were not kept in the mempool of the other blockexplorers. Then, the transaction that you linked would seem invalid to those blockexplorers, because the referenced inputs are not known to it.

You may find this related question interesting: "How do transactions leave the memory pool?"


Does buying bitcoins and not spending them have negative influence of the bitcoin price?

Every investor has a different threshold for risk tolerance. A price one investor might consider as cheap, might be expensive for another investor (read Greater Fool Theory.) If the investor base of bitcoin is considerably large, at any point in time you are highly likely to have two parties trying who will be willing to take opposite positions. Improvement in liquidity, introduction of new financial contracts (futures, derivatives) can go a long way in helping improve the price volatility in bitcoin and attract a wider base of investors.


You need to be running a full bitcoin node like Bitcoin Core, or use a wallet that connects to a bitcoin node. Bitcoin nodes connect to multiple other nodes and distribute the transaction and block data between each other according to the Bitcoin protocol.

Blockchain.com is also running a bitcoin node, and will receive the transaction through the network and display it on their site.


Is Bitcoin Core required for wallet projects?

Bitcoin Core is not required to do anything, but it is a useful software that you can use instead of trying to reimplement everything it does. Or you could use some other software that does the same thing. However Bitcoin Core is by far the most used and reviewed software compared to other node and wallet software.

You can use Bitcoin Core to create wallets and let customers send and receive to/from those wallets. However Bitcoin Core is not well optimized for having a large number of wallets (note that a wallet is not the same thing as an address), so it may not be the best for your use case. Of course, if you instead use the traditional model of one exchange wallet and just giving out depositing addresses to users, it's fine (users should not expect to "send from" "their" address).


Sending bitcoins from wallet without downloading the blockchain or giving up control

You can use an SPV client such as MultiBit. This does not need the whole blockchain, and does not give up control of your wallet.


Can too big hosted mining service be mitigated by allowing customers to choose mining pool?

I think it primarily just gives you a false sense of security.

Let's say company XYZ is a hosted mining company like you describe. They grow so that they have 51% of the network's hash power. This may not be apparent on graphs like this one since it's spread among other (reasonably-sized) pools. However, since they are ultimately in control of the hardware, they can "go rogue" and make all of the hardware mine on their own pool. They now are able to execute double-spends, since they have 51% of the power. Note that this will not be a quiet thing: People will know that it has occurred.

A major reason why this probably wouldn't actually happen is that the company would be killing their golden goose. They could keep making money as a mining service, profiting from Bitcoin's success; instead they succeed in a few double-spends and then faith in Bitcoin is destroyed, and the value plummets. Or, since they no longer have cash inflow from new miners, they can't keep up with the rest of the network's improvements and they fall below 50% of the power. Either way, they're pretty much shot.

If we had a way to provably protect the hardware (via some private/public key system) so that the renters are really the ones that control what pool it points to (and the communication between the pool and the hardware was similarly tamper-proof), we could prevent this sort of attack completely. This would make the service more like a "customer buys some hardware, and we provide the space, power, and cooling in exchange for a fee" service than typical mining contracts.


How to synchronize with the bitcoin blockchain via bitcoinJ

So I think I found the solution to my own question after looking around a bit.

I modified the constructor to explicitly set the peer addresses, like this:

public SimpleExample() throws UnknownHostException {

        walletAppKit = new WalletAppKit(NETWORK_PARAMETERS,DIRECTORY, "test");
        walletAppKit
                .setAutoSave(true)
                .setBlockingStartup(false)
                .setPeerNodes(//Seed nodes for the test network
//                        new PeerAddress(InetAddress.getByName("seed.bitcoin.sipa.be"), 18333),
                        new PeerAddress(InetAddress.getByName("testnet-seed.bitcoin.petertodd.org"), 18333),
                        new PeerAddress(InetAddress.getByName("node3.mycelium.com"), 18333),
                        new PeerAddress(InetAddress.getLocalHost(), 18333));
    }

Another thing I did was to call 2 methods on the WalletAppKit to start the synchronisation:

walletAppKit.startAsync();
walletAppKit.awaitRunning();


Can a transaction have more than one recipient?

Yes, this is possible. Although most consumer wallets will probably not do that, they're simply meant to scan one QR code, send some coins to that address and return the remainder to a change address you own yourself.

I'm fairly sure the Bitcoin-qt GUI wallet can create transactions to multiple destinations. Command line certainly can do everything.

  Later on if Person C sends the same Bitcoin to Person B, will it be possible for person B to verify that, the Bitcoin which it now received from Person B and the one which it already received from Person A, were from the same source ?

This is possible, using a block explorer it's easy to manually trace coins.


What is the role of miners in Blockchain?

Welcome to Bitcoin.SE!

It is necessary to validate all transactions since it is possible otherwise for A to just broadcast a transaction sending 7 BTC to B even if he does not have enough. A could easily write his own program to do so.

Validating all transactions and the entire blockchain is necessary for Bitcoin to have any value and to ensure consensus rules are followed.


My bitcoin transaction has not cleared in almost a month because I accidentally set the fees too low. What can I do?

You can spend in another transaction the outputs used in the limbo transaction. Off course, you need to put an higher fee so the new tx will be confirmed and the old will be invalid.


What is the difference between mining with multiple workers vs single?

Depends. Generally you'd use multiple workers when you have multiple machines (ie graphics cards, mining rigs, or a farm of USB sticks). In some cases you could have them all combined and contributing to a single worker but usually this is not desirable because you'd want to keep track of how each device is performing.

If for no other reason, that certainly makes it easier to tell which one has crashed or is not working when problems arise.

Some hardware&software combinations might produce slightly more from running on two workers at once but in most cases I think that's unlikely.


Why does Coinjoin need multiple participants to increase privacy?

The only advantages of doing a coinjoin is that the recipient of your funds cannot see the source of your funds (and the sender of funds to you cannot see your future transactions). If you do a coinjoin with only your funds, any branch they follow along this trail will lead to a source (or destination) of your funds.

Every source you include in the coinjoin will thus be exposed. Your recipient, of course, won't know that they're all of your sources, but if they're keeping a log of addresses that are likely tied to your identity, now all of those addresses, and only those addresses, will be in their log. If you instead do this with other people, it muddies such a log with false leads.

Similarly, the sources of your funds will all have logs of that destination of funds. Also, they can follow the chain back and deduce that your address is likely tied to another address if you have multiple sources, and they will all have an list of your other addresss. Again, they won't know that the other address are necessarily your address, but they actually will be, and so their log will contain accurate address linkage data.


Anyway I can track the guy behind the bitcoin address?

No, there's no way for an individual to tie an arbitrary address to a specific person. However, it is sometimes possible for companies or governments to do so if the person went through a KYC/AML or identity verification flow on a centralized exchange site (i.e. Coinbase).

This is how the IRS was able to track people with large returns down for tax purposes (https://tokentax.co/blog/does-coinbase-report-to-the-irs/).

All bitcoin transactions are entirely public, just pseudonymous. So, if a company is able to tie an individual to any address, they can easily track where that address sent coins and go from there. So while you might not have any course of action yourself, it could still be worth reporting any information you do have to authorities.


How do I make multisig transactions using hardware wallets truly trust minimized?

Ben Kaufman did a tweetstorm on Twitter on the 10 rules for verification on a Bitcoin hardware wallet.

Rule #1: DO NOT TRUST THE COMPUTER SCREEN.
The very reason for using a hardware wallet is that your computer IS
compromised, trusting it makes using the hardware wallet an expensive
security theatre (or 2FA at best). Always verify on the HWW device
screen!
Rule #2: Verify your "receive" addresses BEFORE accepting funds.
A compromised computer can be tricked into displaying addresses that
belong to an attacker. The only way to make sure you own the addresses
is to display them on the HWW device and verify they match.
Rule #3: Verifying change address should be done by the device when sending funds, not before like receive addresses!
It is pointless at best, and misleading at worst, to verify them
beforehand like receive addresses. All hardware wallets support
verifying the change address belongs to you AT TIME OF SIGNING A
TRANSACTION. Verifying before that is pointless and error-prone.
Now let's talk some multisig...
Rule #4: Verify the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
This is not 100% mandatory - but if you're no expert - you really
should do it. If a hardware wallet doesn't support displaying the
xpub, (like Trezor), it could be fine to just verify each address on
it - so long as you verify consistency on all other devices as well,
but I wouldn't recommend such a device for non-experts.
Rule #5: Verify "receive" addresses on EVERY device of the multisig quorum.
This is especially true for at least one address (see next rule) but
recommended for all. If using a device that you haven't verified the
xpub of on-screen, you should verify all receive addresses on it!
Rule #6: While it is best to verify each receive addresses on ALL devices in the multisig setup - you might choose to trust a specific
one, verifying the xpub/ first address on all - then the rely only on
the "trusted" device - ONLY IF YOU ALSO VERIFY XPUBS...
By that, I mean verify on the "trusted" hww used for general
verification, that the xpubs are consistent for all cosigners. This is
needed only once with wallets like ColdCard, Cobo Vault, Bitbox02, and
Specter DIY - since they allow saving the multisig xpubs on the
device.
With Trezor T - you have to verify the xpubs of cosigners every time -
which is why it's not recommended for that purpose - with Trezor One
it's simply not possible...
So while you might use a Trezor in a multisig, I would not recommend
it to non-experts.
Rule #7: Do NOT use Ledger in a multisig setup! (unless you are an expert or have a very good reason...)
Ledger currently does not allow verifying multisig addresses on the
device - nor displaying the XPUB on its screen.
This means you have no way to verify it was not swapped by an attacker
in your multisig setup - EVEN IF YOU DO A SUCCESSFUL TEST TRANSACTION!
It is still possible for a (very) sophisticated attacker to make you
think it worked, while it was him signing for you...
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and
rely on that paper list for your day to day verification. This is very
useful for multisig! - where devices might be distributed in various
places.
Rule #9: Multisig change verification should be the same as with Rule #3 - on the device at the time of signing.
Popular devices (besides Ledger as said), can verify that the address
you send from and the change address used belong to the same multisig
wallet (from same xpubs).
If they fail to verify the change address - they will show it as a
standard, independent, recipient - in that case YOU SHOULD NOT MAKE
THE TRANSACTION. This is valid for both single sig and multisig!
(although even more relevant for the latter).
Rule #10: Hardware wallets cannot verify your balances - and that's great!
Verifying balances requires getting information from the Bitcoin
network - i.e. you need to be online - which would make hww more
vulnerable... This is where a full node comes in!
It is strongly recommended that you run your own Bitcoin full node -
and use it as your main source for verifying your balances and
transaction history! For redundancy, you could double-check against
block explorers or another node (use a different device for either!).
One last thing: These rules apply to any device you use as a
segregated signing device - be it a "traditional" hardware wallet, an
airgapped laptop, a mobile phone etc.
If you want to separate your keys without having a security theatre,
you should verify on your signing device!
Please note: Some things here might not be fully accurate for the
expert user (especially around multisig address verification), but for
the less advanced users' sake, I have tried to be on the safe side
when things get tricky...
Also check out some more info on multisig setups over at
https://btcguide.github.io (Michael Flaxman guide)


The amount is encoded as a little endian signed 64 bits integer.
Here is how you would decode your sample in Python:
>>> int.from_bytes(bytes.fromhex("f0ca052a01000000"), "little")
4999990000


Bitcoin payment sent and confirmed in blockchain but still not yet received by the account

You sent $10 to an exchange, instructing them to send BTC 0.0016 to an address.
If you look up your transaction 3f624c15d2479ac6aa696b7357fcb650bf29d442f1a980a65488da3bd9501a48 in any "blockchain explorer", for example here,  you'll see this transaction had 2 inputs and 20 outputs. I guess this was an exchange from whom you purchased $10 of BTC and asked them to send it to 1D3HZXK8So3n6LahCGWpkAxbQ3P6br1gSs, the exchange probably combined your transfer with other people's to save transaction costs.
One of those output addresses was the "account" you mentioned.  1D3HZXK8So3n6LahCGWpkAxbQ3P6br1gSs. It received ~$10 in this transaction. Note that this is a Bitcoin address not an account number.
But you don't own that address.
However the $10 of BTC sent to this address is now marked as spent. Three hours after your transaction, it was moved to address 19d1iU8XvYAdPVbCKHExD8hNqbC7T7NwW5 along with 22 other inputs.
The earliest transaction for your address was April this year. From what you write I suspect you did not have control over this address that long.
It could be that addresses 1D3HZXK8So3n6LahCGWpkAxbQ3P6br1gSs and 19d1iU8XvYAdPVbCKHExD8hNqbC7T7NwW5 are both owned by some business (not by you) who swept the $10 and other small amounts into a different address for privacy or other reasons.
Scam?
You mention "account" and "earnings" and seem confused. These are strong indications that you are the victim of a scam.
It is safer to hold Bitcoin in a standalone wallet, not in a hosted wallet run by a website. Many websites are fraudulent, especially any that promise high earnings (or any earnings at all). It is important to take care to investigate any website before sending money to one. Do you know the names of the people who own the business? Do you know when they first registered the domain name used by their website? Do you know where their business is based? Can you check any of this independently from them?
A scammer may show you a web page that makes it look like your $10 has grown to $20. They might encourage you to invest more. If you ask about withdrawing money they might tell you about a withdrawal minimum amount you didn't know about before, they might say you need to send a withdrawal fee or some other fees. They might try to trick you with watch-only wallets or other deceits.
Business relationship
The business running the website you opened an account with might be legitimate. We can't help you much with your relationship with them. A legitimate business will have a support telephone number or other way of contacting them and resolving your problem.
What to do
I suggest you forget about your $10, at least for the next few weeks. Spend some time learning how Bitcoin works, why it is high risk, why it is very hard to earn any money with Bitcoin investments in October 2018, how various scamsters operate, how to choose a wallet, how to backup a wallet and private-keys, how to test recovery from your backup actually works, how to make sure someone you love gets your Bitcoins if you are run over by a bus tomorrow (20-30% of all Bitcoins are lost forever).
No private-keys, no Bitcoin
This is a common saying. It means, you own no Bitcoins if you don't know your private key and don't know for absolute certain that no-one else knows your private-key (e.g. by having known your wallet's old password at any time in the past).


I'm sorry but a "mining wallet" doesn't exist. There's only cloud mining that is questionable. The rest don't won't hurt you so feel free to explore. Just avoid 1) malware 2) Paying (even if they say you have $3k, pay to withdraw)


How can I access the coins stored in the Cryptobridge wallet?

According to Cointelegraph in late 2019:

  [CryptoBridge] announced that all of the firm’s services and servers will be terminated within two weeks. Users will be able to withdraw funds from the exchange until Dec. 15 — the last day of operation.

I'm not familiar with CryptoBridge but it seems like they acted as custodian of Bitcoin and other cyptocurrencies and used their Bitshares blockchain to keep track of their customer's funds. If so you don't have any direct way to recover control over the money that you transferred to CryptoBridge.

Any keys or backups you have might only give you control over their Bridgecoins and those appear to have no value now and are probably not exchangeable into other cryptocurrencies.

  I am hoping that this simple question has a simple answer, even if that answer is: "You can't."

I think that is the simple answer.


Is there an escrow-like mechanism that doesn't involve a trusted 3rd party?

There's "Decred cross-chain atomic swapping". It allows two people to exchange cryptocurrencies (currently BTC/LTC/Vertcoin/Decred) without trusting on a third party nor each other.

UPDATE: There's also Lightning Network atomic swap.

You can read about it on Decred blog or Github


How to derive public child keys from public parent keys with bip39-libs.js?

bip39-lib.js works along with bip32-lib.js AND bitcoinjs-lib.
BIP39 is strictly regarding the mnemonic phrase and HD seed.
In order to derive child keys from an HD seed you'll also need to use BIP32.
BUT... BIP32 has no concept of addresses either so ultimately you'll also need bitcoinjs-lib.
In other words you need to use all three libraries to go from mnemonic to a usable address.


Will bitcoin core have to re-sync the whole block chain if I replace my wallet?

No, it will not need to redownload the entire blockchain. It may need to rescan the blockchain, but that does not require downloading any of it and will not take as long.


Re-use change address as a receive address

Technically speaking, is it possible to reuse a change address from a previous transaction and make it a receive address?

Technically that would be possible. The network rules have no concept of change or receive addresses - it's just a scriptPubKey that coins are sent to.

What are the pros and cons of doing so?

I see no reason why you'd want to do that. It's bad for privacy as it's gratuitously exposing linkage between transactions.

Are there any wallets that currently support this functionality?

I hope not.


How to sign a message using Bitcoin private key?

Using bitcoind and bitcoin-cli you can do it as follows:

bitcoin-cli signmessage 1DiWX6p3FdHPZqN88vMeGVXSwAQ1h7BeVj 'Hello world!'


How does mining process takes Approximately 10 minutes?

To make it simple:

Mining consist on finding a specific block that once hashed gives a value bellow a certain threshold (the target).

The target is recalculated every fixed amount of blocks (2016), so that it is refreshed every two weeks (at 1 block per 10 minutes rate).

When recalculated, the total network hash rate is taken into account, so that according to that value a block will be mined every ten minutes on average. Notice that this is purely probabilistic.

How does it work?

The target is a 256-bit value that is reset periodically. When a block is mined, the SHA-256 hash is performed over the block and the result is compared with the target.

Now, if the target is a huge 256-bit number, the hash of the block will be easily smaller than the target, and the block will be considered valid. However, if the target value is really small, finding a valid block will be way harder. Here is where the network hashrate comes into play. The bigger the hashrate, the lower the target. So, once 2016 block have been published since the last update the target will be recalculated, making it higher or lower depending on how the total network hashrate has evolved.

Notice that it could happen indeed that a block is found in less, or more, than the 10 minutes, but the odds are more likely to be around the mark.

How is it calculated?

If you want to know exactly how it is calculated, here you have a Python code that does so:

max_tgt = int("00000000FFFF0000000000000000000000000000000000000000000000000000", 16)  # Around 2^224

current_diff = 440779902287

current_tgt = max_tgt / current_diff  # current_diff = max_tgt/current_tgt

hash_rate = 3310469378 * pow(10, 9)  # GHash/s to Hash/s

print current_tgt/float(pow(2, 256)) * hash_rate * 600

By dividing the current target by the maximum number of possible hashes (2^256) you get the odds of finding a valid hash. If you multiply this by the hash rate you get how many correct hashes will be get in a second. Finally, by multiplying it by 10 minutes (600 seconds) you get how many valid hashes, on average, you will get in ten minutes.

What gives you:

1.04920216926

Data such as maximum target (max_tgt), current difficulty (current_diff) and hash rate (hash_rate) has been obtained from bitcoinwisdom, and matches with the current network data. There you can also find some charts about how the hashrate and the difficulty has evolved in the last months.

For those wondering how the network hashrate is actually computed, you can check it in this answer.


Bitcoind, what's the command to see available funds?

bitcoind getinfo

The Bitcoin daemon supports just one wallet, not multiple.


Is it correct that more than 160 bits of input data for producing a private key are superfluous?

No, that's not correct at all. If someone knew that your private key contained 96 zero bits, their search space would be drastically reduced. 256-bit private keys are used because they are the minimum considered sufficient to provide the level of ECDSA security required. 160-bits can be used in the hash function because hash functions get more security per bit than ECDSA does.

You could, however, use 160-bits as a seed to generate a 256-bit ECDSA private key. For example, you could use a SHA-256 hash of a 160-bit seed as your private key with no loss of security. You can even go down to 128-bits with no significant loss of security.


Get non-wallet transactions using bitcoin rpc (gettransaction)

Enable txindex=1 in your bitcoin.conf (You'll need to rebuild the database as the transaction index is normally not maintained, start using -reindex to do so), and use the getrawtransaction call to request information about any transaction (it won't work for the genesis block's coinbase transaction though, it's a special case).

Note that this will only give you raw transaction data (you can add a 1 argument after the call to have it decoded instead of in hexadecimal notation), but it cannot know the payment amount or fees, for example.


Every transaction references input UTXOs (also called VOUTs) as VINs and outputs bitcoins to certain addresses. The input value, in bitcoins, is summed up. This sum is the maximum amount that can be allocated to outputs, but does not need to (and usually is not) what is completely allocated to outputs.

Usually, the sum of outputs is slightly less than the sum of inputs. In Bitcoin, the difference between these two is paid to the coinbase address of the block that the transaction is included in.

Most likely, your client uses the "change address" paradigm. From your HD wallet, a new key pair and address are derived. This new address serves as a change address. You specify how much bitcoins you want to spend to an output(s), the remaining amount is then calculated from the subtraction of all the specified output amounts. This remaining amount is then subtracted further, using a fee estimate. The final value is paid to that change address, which you control. The fee estimate then becomes what is paid to the miner. All of these operations are automated by your wallet client, so you normally don't need to fiddle with these change addresses. However, it can be customized.

Following this logic, all you need to do to customize your fee is to increase/decrease the number of bitcoins sent to your change address. The higher the number, the smaller the fee, and vice versa. After calculating all these parameters, you can then create a custom transaction, serialize it (createrawtransaction), sign it (signrawtransaction), and broadcast it.


How can I know what's e-wallet name provide the wallet (...) When I know xpub and xprv and mnemonic?

You cannot. A mnemonic seed phrase, xpub, and xprv does not explicitly contain information about which wallet software was used to create that wallet. Generally this is not any issue to the user though, as this information alone should be enough** to recover the wallet, using any software which follows similar standards.

** you may also need information about the derivation path used, and the address type, in case the original wallet did not follow one of the more well-used standards


Can RBF be done by a third (or second) party

No, without knowing the private key it is not possible to create valid transaction and pay additional fee. There are some other complicated ways to force the transaction be included into a block, for example CPFP or creating non-final transaction ANYONE_CAN_PAY.

The simplest solution is seting the cost to 0.9998 BTC, user will pay 1.0 BTC with 0.0002 fee. This will produce the same result as in your example but without any additional actions.


Are there decentralized bitcoin asset management systems out there?

I think that these systems maybe what you are looking for:

Open Transactions -  A general open peer to peer crypto asset system.
CounterpartyD - a New Asset system based on on Cryptocurrency

EDIT 20/05/2014

You should also check out NXT Crypto Its looking very promising the system they have developed.


x=10

for thing in range(0,x): wallet.create_new_address()

listaddresses(True,False,False,False,True)

A guide about console commands is here. Thanks to @RichApodaca for pointing that out.

Another resource is the code itself. For example you can see the function declaration for listaddresses here which tells you what all those boolean args are for. In the above case it only outputs unused addresses in the external (receive) chain.


Does any current SegWit or blocksize increase proposal also seek an increase in the OP_RETURN byte limit?

Currently, there are no BIPS (Bitcoin Improvement Proposals) that seek to increase the 80 byte limit as you can see here.

Doing a cursory search on that repository, you can see that only a few mention OP_RETURN at all.


How to increase the speed of synchronisation?

Pass -dbcache=N as a command line option. N is a number in megabytes, and setting it higher significantly improves verification speed. The default is 450, but up to 6000 or so you can notice improvements.

This is superior to using a RAM drive.


Is it possible to splice a new participant into a LN channel factory?

You are correct. It is not possible to get Diana into the Channel Factory without a transaction that closes and reopens with Diana.

Splicing-in and splicing-out as explained by Decker et al. in the paper you mention is not secure.

Imagine the following situation:

Alice, Bob and Carol spliced out Dave by creating a new Allocation within the same factory, similar to how Decker et al. explain in figure 9 of their paper. Bob and Alice might tell carol that R^2 is the last update of their channel, but actually they updated to R^3, completely invalidating the new allocation. Carol might have accepted payments in such new factory that will never be reflected. For this same reason, splicing in users is also not secure.

Ranchal-Pedrosa et al. refer to this problem as the broken factory, and suggest alternative factories constructions, comparing them, in their paper Lightning Factories.


Error help! "A fatal error occurred. Bitcoin can no longer continue safely and will quit."

It appears that your wallet.dat file is corrupted. From your log files with the original copy of the wallet, it looks like you made that copy of the wallet before Bitcoin Core closed the wallet database (which actually includes more than the wallet.dat file but those other files are temporary and only exist when the database is open) which has resulted in corruption.

Since you have already used -salvagewallet on a different wallet file, just use that wallet.dat file. Note -salvagewallet has some issues and is not guaranteed to fix corruption. Because your wallet is old enough, it does not use HD keys, so the following workaround should work: start Bitcoin Core with the -usehd=0 option or add usehd=0 to your bitcoin.conf file.

This is a workaround and should allow you to open your wallet and retrieve your private keys. Your wallet.dat file is still corrupted and you should stop using it immediately. You should move your coins out of that wallet file ASAP by following the instructions here.


The term "coinbase" is used to mean many different things. But the two you're probably asking about are:

The "coinbase transaction" is the transaction inside a block that pays the miner his block reward.
Inside the coinbase transaction is a field that is called the "coinbase". It's the generation transaction's equivalent of a scriptsig. Since it doesn't claim any existing outputs, it needs no normal scriptsig. It's basically just a random value that the miner can use as an additional nonce. BIP 34 changes this a bit.


Namecoin: is there any rationale behind the (apparently foolish) choice of having the domains cost an irrelevant price?

When I first looked into this issue the low price for name operations struck me odd, too. But the rationale behind it is to allow to register as many names for as low a price possible. You need to realize namecoin is not only about domains and the dot-bit project is only the first large namecoin project. namecoin is a generic name/value accounting system.
Still, because dot-bit was the first project based on namecoin the design had an initially high price for registering names to prevent squatting. Actually it worked very well, if it had not been there I and others would have registered thousands of domains much earlier.

there was a discussion about fees and thoughts about modifications here: http://dot-bit.org/forum/viewtopic.php?f=2&t=360

By now almost a 60000 domains have been registered so imho it is more important to have low name prices to allow other usage of the namecoin system than to further prevent squatting: possible use cases


Who would accept confirmations of invalid transactions in a 51% attack?

You are guessing that even with 51% of the network hashrate, an attacker can still not benefit from invalid transactions. However, the usual idea of a 51% attack is not to create invalid transactions, but to remove valid transactions, as if they had never happened.

For example, if Sam makes a valid transaction in payment to company XYZ, and then receives the item or service they paid for, having 51% of the network hashrate may allow them to go back to the block before they made the payment and create blocks that are similar to the existing blocks but do not include that payment. If they continue producing valid blocks until their chain is the longest, then the rest of the network will use this chain and continue adding blocks to it. This would mean that everyone else in the world would see the blockchain without problems with the correct balances, apart from company XYZ who provided the item or service. That company would now find themselves without the payment, as it would now appear never to have been paid in the first place.

EDIT: As explained in dchapes' comment below, the original transaction may still be held by other nodes, who would simply add it to a later block once the attack is over (so company XYZ would see the payment disappear, but then reappear later). In order to prevent this happening, Sam would have to include a new transaction which spends (at least some of) the money elsewhere. Provided the input address then has less than the required amount to validate the old transaction, the old transaction will be rejected by the network and company XYZ will never receive the payment.


Does the miner first validate transaction before doing POW or he does not validate at all ?

Miner first validates all transactions he wants to include in the block he will mine.

Then from these transactions he calculates their Merkle root, that becomes the field of this block's header.

Then he mines (repeatedly hashes this header modifying its nonce field with each try).

When he finds the correct hash he broadcasts this block (including block's header and transactions) to the network.

Reasoning: It would be stupid from miner to do the expensive work of mining before making validation, risking the block to be rejected. This would mean he spent a lot of resources to mine the block in vain.

Nodes validate the transaction before relaying it.

Reasoning: It is beneficial for network if the nodes filter invalid (erroneous, malicious) traffic. It reduces the load.


The transactions are already there when you are mining. You are hashing the block header which contains a merkle tree root that connects the list of transactions and block header together.

After you hash a valid block header you can't add any transactions as it would change the merkle root and the hash would not be below the current target anymore, so the block becomes invalid. This is also the reason why you can't mine in a pool and take the coins yourself if you find a valid block. That would require changing the generation transaction, which changes the merkle root, and the block is then invalid.

Mining is both about generating new coins (they must come from somewhere) and processing transactions (we need a ledger that everyone can agree is the one true ledger).


Does the Ripple protocol allow listing an account's (address's) past transactions? If yes, is there a web site for this?

Yes, the Ripple protocol does allow you to list all past transactions performed. The most typical way would be to use the account_tx command. You can "page through" the data, retrieving a particular number of transactions per command, until you get to the first transaction.

I am not aware of a website where you can trace through an account's transaction history using GUI-style navigation, although the Ripple Charts Account Explorer will show you an account's transaction stream.


How do you know that Block, the Merket Root & the hashes in the path are authentic?

Forget about the Merkle tree. Assume that instead, the block header would just contain a hash of the concatenation of all transactions.

A lightweight node could then download all headers, verify their proof of work, and make the assumption it has seen the longest chain. It is now convinced it has seen the chain the network accept. This is different from a full node, which does not assume a chain is accepted until it has seen all block data and verified every single transaction.

Now the lightweight client decides to ask peers for the actual block data. When it receives a blocks' transactions, it knows they actually match what the block header committed to, as it can recompute the hash, and compare it to the value in the header.

But what if the lightweight node is not interested in all transactions? BIP37 introduces the concept Bloom filtered blocks, where a lightweight node can reveal what keys/transactions/addresses it is interested in, and the full node it is downloading from will only give the transactions that match the filter.

Unfortunately, if the lightweight node does not download all transactions, there is no way to know whether they match the hash in the header, and as such, the full node could lie, and include transactions that are not actually present in the chain.

Enter the Merkle tree.

Instead of just storing a hash, we store the root of a Merkle tree. The full node can now for each matched transaction include the hash values that transaction's hash is combined with, to prove that the transaction is in fact included in the tree, despite the fact that the lightweight node only knows the root.


Wallet as daemon, what's the security-concern about "rpcallowip"?

if anyone guesses my server and credentials, he/she is welcome to mine
  for my wallet.

He/she can also call all other RPC commands. For example, sendtoaddress. So, if your wallet is unlocked you can loose your coins.


What can I do with Account Extended Private Key and Account Extended Public Key?

I read that Account Extended Private Key should be kept private because if others got hold of it, they could sign the transaction with the key, effectively stealing your cryptocurrency. How does this work exactly?

  Also, I read that Account Extended Public Key should be kept private as well because exposing it to others allow them to go through the transactions. How does this work?

Extended keys allow for private and public keys to be derived from them. This is done using the algorithm described in BIP 32.

Your Account Extended Private Key is used to derive child private keys which are the actual private keys for your addresses. If someone gets ahold of this extended private key, they can derive all of your private keys and thus spend your Bitcoin.

Your Account Extended Public Key can be used to derive all of the child public keys in a similar way to how the Account Extended Private Key can be used to derive all of the child private keys. Knowing the public keys means that the addresses can be derived and thus anyone who has your Account Extended Public Key will know all of your addresses. They can thus observe every single transaction you receive and make.

  Is there an application that I can import other's Account Extended Private Key and send certain amount to my other wallet's address?

  Is there an application that I can import to view the transaction history?

You can import extended keys (public or private) into Electrum which will scan the blockchain for transactions related to child keys derived from those extended keys.