How does a Trezor passphrase prevent restoration of a wallet if an attacker knows the seed?

The seed is protected with a password or PIN; it precludes the possibility of stolen devices being decrypted whilst online malware/rootkits are precluded by the hardware device being separate from the compromised OS's memory pool.

From Trezor:

  TREZOR’s PIN based security system is a powerful tool to keep your
  bitcoin’s safe. If your TREZOR is stolen, the only thing between the
  thief and your bitcoins is your PIN and/or passphrase. It is
  imperative that you choose a good PIN!


Would bitcoin be destroyed if a wealthy organization obtained a CPU majority for a sustained period?

One of the questions you linked to has the wrong chosen answer— Bitcoin can also be destroyed by a sufficiently deep pocketed attacker which corners sufficient marketshare of coins to enable causing debilitating volatility. Probably won't require any where near majority share to create volatility. I added my claim at that question.

Yes Bitcoin can also be destroyed if an attacker cornered sufficient Proof-of-Work to disrupt the system. Even if developers release new protocols after the attack, there will be chaos as to which fork to trust and reputation will be shattered.

Might not even require 51%, as the minority share attacker could cause many transactions to be randomly delayed, which is also potentially debilitating to a currency.

As the prior answer points out, one the keys to hardening a P2P currency is to make the Proof-of-Work more difficult to corner. But that alone is not sufficient, as the volatility of the value is another attack vector. I am contemplating solutions to harden against both classes of vulnerabilities.

Bitcoin might even be attackable simply by talking and enumerating the flaws in it. We could see a crash at any time if enough people become concerned. So public opinion is another attack vector.


Possibility of contructing a valid transaction without knowning private key

Yes, but that is hard. This is known as a collision, and you would be finding a collision in SHA256. Because you would be reusing a known hash, what you would be doing is performing a preimage attack. Since SHA256 has no known preimage attack for all 64 rounds done in a normal SHA256 hash, you would need to do 2^256 hashes in order to be guaranteed to have found a colliding preimage for that hash.

This is why a cryptographically secure hash is used for signing operations.


Accessing bitcoind from python module hits error


How to Create or Generate a New UTXO in Bitcoin Core?

"Creating a UTXO" is the side effect of transacting. It's an abbreviation of "unspent transaction output"
A transaction in Bitcoin consumes a number of UTXOs, and creates a number of new ones, possibly assigned to new owners.
So the answer is: send BTC somewhere (possibly to yourself).


C# parse bitcoin blockchain to get balance of an address

How about running a QBitNinja server locally?

var client = new QBitNinjaClient(baseAddress:"specify host here, you probably want localhost", Network.TestNet);
var balanceModel = client.GetBalance(dest: [Add any IDestination here, like new BitcoinAddress("mivD5GHroixrzgjv6Ww73pV5R55PcL8JdM", Network.TestNet)], unspentOnly: true).Result;
if (balanceModel.Operations.Count == 0)
    throw new Exception("No coins to spend");
var unspentCoins = new List<Coin>();
foreach (var operation in balanceModel.Operations)
            unspentCoins.AddRange(operation.ReceivedCoins.Select(coin => coin as Coin));
var balance = unspentCoins.Sum(x => x.Amount.ToDecimal(MoneyUnit.BTC));


How secure are current deterministic wallets?

It is secure.

128-bit seed is at this time very secure. It is lower than a regular bitcoin address which is actually RIPMED-160(SHA-256), giving it 160 bits of entropy.

Brute forcing a 128 bits of entropy at this time would take around 1,440,000,000 years if every computer ever made was working on this single problem.

Like most of these algorithms brute forcing is not the issue. Side channel attacks are usually the danger or if an error is found in the implementation, which none have been yet.


How/where is the informatioin regarding the mapping of a transaction to a particular block stored?

The merkle tree is dynamically recreated to validate it in a block, the order of transactions in the block implicitly describe what the merkle tree should look like when reconstructed. The transactions are stored as part of the block, quite literally the header, a number stating the number of transactions to follow, and then a list of all the transactions follows.


They will probably be confirmed eventually. But you don't have to wait. You can just form new transactions that spend the same outputs with the normal fee. The fact that there exists a conflicting unconfirmed transaction will have no effect on other transactions that attempt to spend the same outputs. You can be 100% sure they won't both go through, since an output can only be spent once. Unfortunately, depending on what tools you have, this may be difficult to accomplish.


What's the maximum possible utxo growth rate now? Can that be turned into an attack?

There is no limit on the size of the UTXO other than the block size as you've described, but your reasoning isn't correct. There is no minimum size of a transaction output, nor maximum number of outputs per transaction. The bulk is limited by the Bitcoin block size of 1MB, or about 50GB per year total additions if the only thing being added was spam outputs.

Volume of outputs is another matter entirely. The smallest possible output is 0 BTC (8 bytes), 0 length (1 byte), null scriptPubKey. If we make a maximum sized transaction (1MB) of these it will have somewhere in realm of 110,000 outputs, with some loss included for inputs and structure. 6 blocks per hour, 24 hours gives 15.8M outputs per day. Note this does not include any indexing overhead, which would be non-negligible for this many entries.

Some of the proposed solutions include expiring unspent outputs after a particular amount of time, or significantly moving the cost towards creation and incentivising removal of entries. Changes in core operation like this however aren't fast to implement or uncontroversial, and are not a complete solution against an attacker.

It's one of the drawbacks of the system as implemented and something that needs to be seriously considered before making alterations which could make the problem even worse.  Lots of things become unpalatable in Bitcoin when you change the constants, this is one which is already pretty terrible to begin with.


Using BTCPay To Accept Undefined Payment Amounts

I separately sought help on this issue from the BTCPay Server support channel, and with their help have devised a 'work-around' for this problem.
The initial response from their support is paraphrased below:

BTCPay Server does not currently support API access to the wallet, and
it is not [currently] possible to generate ad-hoc receive addresses
programmatically.

After a discussion, the method that I suggested in point 1 above seemed the most suitable:

Generate a very low value invoice in BTCPay Server (for example, for 0.000001BTC).  In my case I set the invoice expiry to be 24 hours as my clients will not necessarily pay immediately.
Send the payment address\QR code to the client for payment.
The client makes a payment of whatever amount they have decided.
The invoice is marked as 'over-paid'.  That is, the client paid more than the invoice amount.
In my software, I credit their account with the actual amount they paid.
Generate the next invoice for the client (which will need to be done each 24 hours as the invoices expire).

Unlike BitPay, BTCPay Server does not automatically refund overpayments.  This is critical to the solution working - as I am expecting clients to pay an indeterminate amount but it will definitely be more than the very low invoice amount.
References
The following references are from my conversation with BTCPay Server support on their Mattermost support channel.
Ref 1 (Receive addresses and wallet API):

So we don't have a wallet API yet. BTCPay is compatible for the most
part with BitPay's API. However, that API is not allowing the full
potential of the software, so we're working on crafting a way better
API. It's still in infancy you can preview docs here and in case you
have some feedback you can join the discussion on GitHub. We don't
have ETA when the new API will be fully ready, probably by the end of
the year.

Ref 2 (My proposed solution)

Thank you for the response. Can I ask if this that I am about to
describe is a viable work-around for now?
Create an invoice for each client for a low amount (such as
0.00001BTC) and then an address is available for a client to send payment to.  They send their payment (which will be higher than the
invoice amount) and then the invoice is flagged as over-paid.
This presumes that the over-paid amount will not be automatically
refunded to the client.
Once received I can then generate a brand new invoice for that client
so that they receive a new address.

Ref 2a (Their response)

sure that would work

Ref 3 (Invoice over-payments)

refunds are done by the merchant, not automatically


How do I know if a transaction is legit?

I've just checked on three different blockexplorers, and none of them knew about this transaction. Your sender may have tried to pay you, but they definitely didn't succeed, so it's up to them to remedy that.

You know that a transaction is legit when it was confirmed in a block and the money has actually been transferred to you. Before the transaction is confirmed, it's merely a payment promise.


Why is trading behaviour so similar across all (mainstream) exchanges?

You, as in the collective you that makes up the trading market.
Whenever the price differs enough between two exchanges, a trader who has an account (and funds) on both can profit by selling on the cheaper one, selling on the more expensive one, and then possibly transferring fiat/BTC to compensate. Of course, there are trading/withdrawal/transfer fees involved in all of these, but if the rates differ enough, it will at some point inevitably be worth it. This is called arbitrage.
Sophisticated traders likely keep funds specifically spread across exchanges to take advantage of this, and may have automated trading bots that trigger buy/sell orders whenever arbitrage opportunities arise.
The result of people exploiting arbitrage is that the price starts to balance out across exchanges.


Yes you can. You can use OP_RETURN of course but there are also other ways, some "hacks" like adding an transaction output that refers to an Bitcoin address that instead of being the hash of your public key is the hash of your file.

Here is what Garvin Aderson said about OP_RETURN

  Why 80 bytes? Because we imagine that most uses will be to hash some larger data (perhaps a contract of some sort) and then embed the hash plus maybe a little bit of metadata into the output. But it is not large enough to do something silly like embed images or tweets.
  Why allow any bytes at all? Because we can’t stop people from adding one or more ordinary-looking-but-unspendable outputs to their transactions to embed arbitrary data in the blockchain.
  What do I mean by “immediately prune-able?”  The form of the up-to-80-byte transaction output (“OP_RETURN ”) is such that it can never be used as an input for another transaction– so it can theoretically be forgotten by everybody except for machines that want to keep a full record of every single transaction (“archive nodes”). That is a big improvement over the various hacks people are using today to associate data with their transactions, and will be more important in the future when we implement code that saves disk space by keeping only unspent transaction outputs and not every old block.

Source Gavin Andresen talks about the 0.9 release


What is the exact consensus protocol Ripple uses?

If the Ripple network splits in half, then each half will validate ledgers independently, potentially with conflicting transactions. If all servers are properly configured, they will not accept any of these ledgers as fully validated, since none of them will have sufficient validations. It's possible both sides will think they're in the minority (if the split is close to 50/50).

This reflects a basic Ripple design principle -- don't tell people they can rely on results if the results are unreliable. If conditions make reliable operation impossible, it is preferable not to operate than to give people results they cannot rely on. Ripple is designed to detect these kinds of conditions.

When the network rejoins, servers will see the other ledger chain. They will gradually avalanche to the chain with more validations until one chain or the other has a super-majority of trusted validators. At that time, the network is back in agreement and everyone can again rely on the results of transactions.


Find the seed phrase you used for your wallet, or open your wallet and transfer them to an exchange.

The actual coins are still on your computer - they are just some strings.
So you need to open your local wallet or restore it using the seed phrase.
Sell the LTC to convert to something else. LTC just isn't worth it.


Understanding Storing Bitcoin and wallets

Welcome to the world of Bitcoin. One hint at the beginning: you raised too many questions at once, usually people here try to limit to one question, and answer it "accordingly". That makes it easier to follow up. Anyhow:

Bitcoins are not stored in a way you would have money in a wallet. The concept of Bitcoin circles around cryptographic keys (private and public keys). These keys are used to create and validate transactions, which transfer bitcoins from an address A to an address B, all noted down in the blockchain.
Your wallet is an abstraction layer, so that you don't have to work with these cryptographic keys. And every wallet has it's own idea on implementation, though there are some common rules. One of the major rules is: as long as you have the private key (on floppy, USB disk, or noted down on a paper), you are quite independant of any wallet.

Now on Multibit: if your PC crashes, your bitcoins must not be lost. You can make backups, and re-install on a new PC. Multibit has some info on the support pages on how to secure your wallet, by making backups and restores. Better read it carefully, and give it a try on a test machine  :-)
The more precise answer is: if you lose you private key (which is linked to the words of the multibit wallet), then and only then the bitcoins have very, very low probability to be somehow recoverd (all your bitcoins are lost).

On paper wallet: generally a paper wallet is a private key or words derived from the private key noted on a paper, so they can be used at a later stage to recreate a wallet (eventually with all its funds). There is a tag in stackexchange for paper wallet: https://bitcoin.stackexchange.com/questions/tagged/paper-wallet
you may find what it is, or do some web research. It has been answered before.

On Multibits use of words: it is not necessarily working in other wallets. It may work, or may not work. I haven't seen someone doing all the combinations - obviously already too many wallets out there!

My hints to all newcomers in rypto world: do some further research, e.g.:
1. the book „Mastering Bitcoin“, in many languages, by Andreas M. Antonopoulos.
2. „www.bitcoin.org“, with a description of the whole eco system, also in many languages.


How to uninstall Bitcoind from ubuntu server?

If you installed with a deb package, you can use apt-get to remove it:

sudo apt-get remove bitcoind


there is no list of bitcoin trusted websites, but you can check some things  to have a good idea of the trust you can give to a website :

check the whois :

anonymous whois ( domainsbyproxy or other ) : -1
recent website ( created 1 or 2 months ago ) : -1
old and known website : +1

check the bitcoinpolice website ( bitcoin.crimeunit.net/wiki/index.php ) there could be a report here ( bitcoin.crimeunit.net/wiki/index.php/MyBitcoin as an example )
if you can use IRC, come ask on #bitcoin-otc and #bitcoin-police IRC channels on freenode IRC server
bitcoin-otc is a p2p bitcoin exchange, building a reputation system ( wiki.bitcoin-otc.com/wiki/OTC_Rating_System ) , if a website is operated by an old and trusted otc member ( example of old trusted user :  bitcoin-otc.com/viewratingdetail.php?nick=ne0futur ) you can probably trust the website.
help us making it better, report any problem to the bitcoin-police


Why does all cold/offline storage setup require three steps?

Building the unsigned transaction requires the input data(transaction IDs, vout, values), and is also good practice to check the network fee climate prior to setting a fee in the transaction you are building.
Technically yes you could do it in two steps but it would be considered for advanced users only and still prone to typos or other errors during the input data entry.
Related repository of mine that lets you skip step 1 and do it in 2 steps if you choose. (NOT A RECOMMENDATION, EXAMPLE ONLY TEST SOFTWARE USE AT OWN RISK) https://coinables.github.io/coldsigner/


How peer discovery works after connecting to hardcoded nodes?

Did you add the hardcoded nodes with addnode or with connect?

addnode=<ip>          Add a node to connect to and attempt to keep the connection open
connect=<ip>          Connect only to the specified node(s)

So, if you used connect, it will not connect to any but the hardcoded nodes.


What exactly is the benefit of buying a hardware wallet for Bitcoin?

Hardware wallets are generally designed to securely store your private keys in an always-offline environment ("cold storage"). This allows the user to have confidence that their coins will not be stolen by malware/hacking/etc, since any attacker would need to have physical access to the device itself.
If nothing else, this is the main advantage of a hardware wallet: the user can securely store their funds, without needing too much technical knowledge or skill.

It's not like I can actually use it in physical stores.

Well, if the store accepts BTC payments then you could, but I agree this is a perhaps less important/rare use case at the moment.

And if I'm supposed to use it as a secure storage device for all my coins, doesn't it just scream "STEAL/SEIZE ME!" to burglars and the cops?

Yes, any educated thief/cop/etc may view a hardware wallet as a target for theft. Most hardware wallets have security against this though, such as a PIN to unlock the device (usually with the threat of wiping the device after some number of failed attempts). Each device will have different features in this way, so as a user you'd have to decide what fits your needs best.
Keep in mind that you can also just use the device to generate a wallet in an offline/secure environment, then create and test backups of that wallet, and finally destroy the hardware wallet device itself. In this way, you could create a cold storage setup, without the added risk of having a device which is obviously a bitcoin hardware wallet in your possession (of course you'll need to keep the backup, but the idea is that the backup may be easier to hide- for example using steganographic techniques).

why buy such a hardware wallet instead of just an encrypted USB stick with a wallet.dat on it?

If the wallet.dat file was generated on a computer which connects to the internet at any point in time (past/present/future), then you will not have the strongest of guarantees that it is not infected with malware. The same goes for the USB stick.
A hardware wallet, on the other hand, should be designed to have extremely restricted communication channels with the outside world, such that the user can have a higher assurance that their privkeys have not been leaked. In many cases, I've seen hardware wallets include a physical confirmation that the firmware running on the device is genuine.
Worth mentioning as well: no electronic device should be used as the only form of long-term storage for a user's funds. Bit-rot and general electronic failure are guarantees, given a long enough timeline. It is very important to have a physical backup of the privkeys as well (think: written on paper, stamped into metal, etc. This backup usually comes in the form of a mnemonic seed phrase these days).

Of course, if you're a technically savvy, then you may prefer to create your own cold storage device, perhaps something as simple as a raspberry pi running Tails as the operating system. But for many users, a hardware wallet offers a great mix of security and convenience, for a reasonable price.
The extremely adversarially-minded user may also feel alarmed at the prospect of a supply-chain attack against a hardware wallet manufacturer. They would be great targets after all! To combat this, the user may choose to use a multi-sig setup, with signing keys generated on multiple devices from different manufacturers, and perhaps even keys from bitcoin-core, etc, as well.

Ultimately, there is no 'perfect solution' for security of your funds, each user will have to make a choice based on their needs, preferences, and comfort level.


How do I report a bug in the Bitcoin client application?

You can use the issues page on github. https://github.com/bitcoin/bitcoin/issues?state=open

You can also search through the issues to see if yours is already reported.


Lightning Network node without opened channels

Running a Lightning Network node without any open channels doesn't really make the Lightning Network more robust. Unlike the main Bitcoin layer, the Lightning Network does not rely on or require other nodes to verify transactions. Thus a Lightning Network node without any open channels is simply a data relayer which there are many (all of the other LN nodes). There really isn't much data to relay anyways, and you relayhing it does not ultimately help LN that much.

The usefulness of a LN node is to provide capacity for routing payments over additional payment channels. Since you do not have any payment channels, your node isn't really helping with that.


What will happen to my bitcoin if both Core and XT remain indefinitely?

Ultimately I believe the chain with most work should be the valid one, suppressing all other chains. In fact if you use an SPV client, such as MultiBit, you don't even check the size of the block, because you only use the headers. So if that's the rule, your money will only ever be in one chain: the one where most computing power was used to generate it.

PoW is entirely democratic: people vote with their computing power and if more people decide they want different protocol rules, so be it. In fact I would go even further and say that this is much more democratic than a bunch of developers deciding what the Bitcoin protocol should be.


Tx to a multisig address in testnet not working

UPDATE: looks like the testnet blockexporer don't know how to handle the multisig addresses (probably because it was hardcoded the p2sh magicbyte from mainnet) and shows them as "strange", but my TX was confirmed ok and i was able to spend the incoming txs.


Does total size of the transaction affect confirmation time?

Yes, but for a different reason than you think. ;)

Transactions bigger than 100,000 bytes are considered non-standard and won't be relayed by most nodes and probably not included by most miners in their block candidates.

Besides that, especially for a transaction paying a thrifty fee, a larger transaction might take longer to confirm. Block templates are by default populated by highest fee rate first as this maximizes revenue. It's more likely to have 192 bytes of block space left than 148,044 bytes after all transactions with higher fee rates have been considered. It's thus more likely for a bigger transaction to be delayed from inclusion in a block due to taking up more space.


What is the best way to create a wallet with a blank keypool then add keys to it?

Yes, you will want to create a new wallet and specify true for disable_private_keys. It is not necessary to specify blank as disable_private_keys will already ensure that no private keys will be generated or imported and as such, the newly created wallet will be blank anyways.

You can then import xpubs, public keys, and addresses into Bitcoin Core using importmulti. By setting "keypool":true for every public key, the keys will be added to Bitcoin Core's keypool and allow you to use getnewaddress to get addresses. Additionally, for change keys, specifying "internal":true will mark change keys as change and allow you to use getrawchangeaddress, fundrawtransaction, and walletcreatefundedpsbt more easily.

However, be careful when importing an xpub that you use the correct derivation paths. If the child keys that you will eventually be using are derived using hardened derivation, you cannot import an xpub as hardened child keys can only be derived from the master private key. In that case, you will have to import each key by itself, which can also be done using importmulti.


How can I get a new Bitcoin exchange up and running?

The easiest way to get a Bitcoin exchange up and running is to start with an open-source exchange project like Intersango and modify as appropriate to your target currency (Profit Points in this case).

As has been mentioned in the comments, however, GLBSE might actually be more appropriate to your intended use-case.


Unfortunately the electrum seed is not compatible with BIP32/BIP44, which is essentially what Coinomi implements, so the answer to your question is no, you cannot import your electrum seed into coinomi at the moment, although this might be possible in the future.


Does testmempoolaccept check all possible rejection rules?

No it's not, or at least not at any point in time.
There are both invariant and time-dependent rules for the mempool to accept a specific transaction.
The testmempoolaccept command will check your transaction against the former (policy and consensus rules), but there is nothing you could realistically do to check the latter.
As an example of a time-dependent rule, you could have a software checking pre-signed transactions paying 253sat/kW of feerate against testmempoolaccept.
Valid transactions would pass the check, nonetheless they would not broadcast if the mempool minimum feerate is > 253sat/kW at the time of broadcast.


Is there a way to pay my credit card balance with bitcoins?

If you live in the states the only service that comes close to this would be

https://www.xmlgold.eu/  - you can even order a pre-paid credit card that you are able to top up with bitcoins.

https://www.okpay.com/en/index.html - Okpay used to offer the same service but due to regulatory reasons they have ceased offering thier services to US citizens.

The only other way I can think of to do this would be to use http://bitcoin-otc.com/  here you  can see if you can find anyone willing to pay off your credit card for bitcoins.  Its kind of like online trading pit.  Hope this helps.


In addition to Lohoris's answer, the reason that litecoin was created was to be as resistant to custom built hardware just for mining the coins, it uses scrypt as its cryptographic function. Scrypt was specifically designed to make it as expensive as possible to create hardware that is specifically good at doing that hash function. I personally like this because I do not like the idea of buying hardware that can only do SHA-256 to mine cryptocoins.

There is also ppcoin (pdf warning) which is aimed at not relying on constantly using electricity to keep the network secure. In this way it is very distinct from bitcoin.


how do you transfer your Bitcoin core wallet while syncing?

Follow this guide.

Summary:

Download Electrum and verify the signature to prove it was not modified in transit. Create a new Standard Wallet and choose "Create a new seed". Electrum will give you a seed phrase which you should write down on paper.
If using Bitcoin-Qt, click Window -> Console.
If your wallet is encrypted, use this command to decrypt it for 5 minutes (300 seconds):

walletpassphrase your-wallet-passphrase 300

If addresses with balance are known:

Use the dumpprivkey command to get the private key. Repeat for as many bitcoin addresses as have money in them.

dumpprivkey <your bitcoin address>

If addresses with balance are not known:

Use the dumpwallet command to get all private keys from the wallet.

dumpwallet path/to/exported-wallet.txt

In the Electrum window, click Wallet -> Private Keys -> Sweep. Paste the private keys from Bitcoin-Qt here. Check the resulting transaction is okay and click Broadcast to sweep from the addresses in Bitcoin Core to the Electrum wallet.

If the address generated from the private key is wrong, then on the Sweep Private keys dialog box in Electrum click the Info box in the upper-right. It will give instructions for prefixing your private key so that the correct address is generated. For example if your address starts with 3 then use p2wpkh-p2sh:[your-private-key].

Warning: Make sure the Electrum wallet is not a watch-only wallet. The Electrum window title bar should not say [watching-only].


Neutrino enables full mining nodes without storing the entire chain?

No, it would not. A node that uses BIP 157/158 is not a full node. It is not downloading every single block and making sure that all blocks and transactions are valid, thus it is not a full node.

You can already run a full node without storing the entire blockchain. For a very long time now, Bitcoin Core has supported pruning where it discards old blocks after it has validated them. Pruned nodes are still full nodes as they still have downloaded and verified every block and transaction, they just don't store all of history. Pruned nodes can be used for mining.


How can one figure out what version of Bitcoin-Core is used most?

Yes.

Go to https://getaddr.bitnodes.io/nodes/, click on the "User Agents" tab.

At time of writing:

1   /Satoshi:0.11.0/    2119 (35.22%)
2   /Satoshi:0.10.2/    1416 (23.53%)
3   /Satoshi:0.10.0/    437 (7.26%)
4   /Satoshi:0.10.1/    418 (6.95%)
5   /Satoshi:0.9.3/     352 (5.85%)

(You can also click on "more.")


There is currently no mechanism known to enforce loan repayments, as the lending happens on the blockchain and the repayment is tied to an offchain contract.

The revenue of Bitcoins is very high, because the risk of the borrower evading repayment is very high.


How do I add a multi-sig address to account to watch balance in Bitcoin CLI

I believe importaddress is the command you're looking for: Bitcoin RPC Documentation

importaddress "address" ( "label" rescan p2sh )

Adds a script (in hex) or address that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.

Arguments:
1. "script"           (string, required) The hex-encoded script (or address)
2. "label"            (string, optional, default="") An optional label
3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well

Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls
may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes.
If you have the full public key, you should call importpubkey instead of this.

Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated
as change, and not show up in many RPCs.

Examples:

Import a script with rescan
> bitcoin-cli importaddress "myscript"

Import using a label without rescan
> bitcoin-cli importaddress "myscript" "testing" false

As a JSON-RPC call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importaddress", "params": ["myscript", "testing", false] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


How to generate the digest from a raw bitcoin transaction for verifying signature of specific input?

However, the length bytes seem to make the entire process extremely
  complex.

Not very complex. Here is a piece of my code for generating digest for standard non-segwit transactions and sighash_all inputs (I do not need and have not tested other hashtypes).

const MyKey32 Transaction::getDigest ( const int n, const QByteArray& scr ) const
{
  MyByteArray data;                                 // create empty array
  MyStream stream ( s );                            // source transaction is a stream
  data.putInt32 ( stream.readU32 ( ) );             // version
  data.putVarInt ( stream.readVar ( ) );            // input count
  for ( int i ( 0 ); i < inputs; i++ )              // copy all inputs
  {
    data.putArray ( stream.readAdvance ( 36 ), 36 );// copy 32 byte hash as is + copy 4 bytes index
    data.nop ( stream.skipVarData ( ) );            // skip original script and do nothing
    data.putPrefixedCond ( i ^ n, scr );            // script replacement: empty or given in param
    data.putInt32 ( stream.readU32 ( ) );           // sequence
  }
  data.putVarInt ( stream.readVar ( ) );            // output count
  for ( int i ( 0 ); i < outputs; i++ )             // copy all outputs byte-by-byte
  {
    data.putInt64 ( stream.readU64 ( ) );
    data.putPrefixed ( stream.readVarData ( ) );
  }
  return data
      .putInt32 ( stream.readU32 ( ) )              // lock
      .putInt32 ( SIGHASH_ALL )                     // append hashcode
      .sha256d ( );                                 // double-sha256
}


after hard fork won't every new transaction go on both chains?

This actually happened on Ethereum when they had a hard fork.  If a transaction is valid on both chains (spends outputs from before the fork), and gets propagated to both chains, then yes, there is no reason it won't be added to blocks on both chains.

However, there are still two chains.  When the same transaction gets added to both chains, they are included in two separate blocks; one block from chain A and one block from chain B.  The outputs of such transactions can only be spent on their corresponding chain, even though the transaction that created them was identical.

Lets say that we have a chain that hard forks at block height 100.  We now have chain A and chain B.  A transaction is created using UTXOs from the block at height 90, and propagates on both networks.  Chain A includes it in its block at height 108, and chain B includes it in its block at height 110 (although it could just as well be 108 on its chain too).  Now a new transaction is created spending a UTXO from the first transaction on chain A.  That second transaction can only ever propagate on chain B if it exclusively spends from UTXOs on both chains.  This becomes increasingly less likely over time.

Since most new transactions on a chain are only valid for that chain, it won't take long before the two chains have barely any transactions in common.

It's also important to note that bitcoin clients will drop connections to clients that propagate blocks from the other chain.  This will help to segregate the network, and prevent transactions from propagating on both chains, even when they are valid on both.  There could be malicious entities that "bridge" the two networks, looking for transactions that are valid on both, but there isn't any real incentive for that sort of misbehavior.


I believe there is a typo. It should instead read Q'=(d+c)G=Q+cG. The private part d+c is an offset of the payee's private part d, so only known to the payee. The public part is an offset cG, known to both.


How to estimate mining fee for raw transaction?

Have a look at fundrawtransaction (if you are okay using the internal wallet).
fundrawtransaction will give you back the used fee (next to the hex byte-array of the funded transaction) before signing or broadcasting the transaction.
The ideal workflow is:

createrawtransaction '[]' '{"<addr>": <amount>}' //set no inputs
fundrawtransaction <hex>
you'll get back {"hex":<tx>, "fee": <amount>, "changepos": <pos of the change output>}
Check the fee, maybe increase it (requires Bitcoin Core 0.14, use the feeRate of fundrawtransaction.
signrawtransaction <hex>
sendrawtransaction <hex>


bitcoin had more power than the top 500 supercomputers

This is a nonsensical comparison.

Sure, nothing compares to the aggregate of all Bitcoin miners in quickly computing the last 32 bits of the double-SHA256 hash of particularly structured 80-byte inputs.

But at the same time, Bitcoin mining hardware can also literally not do anything else. It can't even multiply two numbers.

You simply cannot compare specialized Bitcoin hashing hardware with general-purpose supercomputers. Each is designed for a certain goal, and very good at that goal.

  Is bitcoin the most powerful computer network in the world?

If you're going to define network so abstractly, I'm sure that the Internet has a lot more computational power connected to it.


Can I use curl to call getInfo from a the Bitcoin server?

You can use the command-line curl or any of the various JSON-RPC examples listed here.
In particular, you can use curl like this:
$ curl --user <username>:<password> --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

For PHP, you can use this library and do:
require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<pre>\n";
print_r($bitcoin->getinfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";


Do bitcoin miners calculate the hash value of current block or next block?

After reading your question, you are a little confused, so i will try to explain:
Miners do double round of SHA256
What they hash?
They hash the blockheader...
What's the blockheader?
The blockheader is build from data
What data?
It's Build from:
Version: The version of the block.
Previous block hash: The Block Hash of the block that this block is being built on top of. This is what “chains” the blocks together.
Merkle root: All of the transactions in this block, hashed together. Basically provides a single-line summary of all the transactions in this block.
Time: When a miner is trying to mine this block, the Unix time at which this block header is being hashed is noted within the block header itself.
Bits: A shortened version of the Target.
Nonce: The field that miners change in order to try and get a hash of the block header (a Block Hash) that is below the Target.
All this is in little endian


From the glossary:

  Selecting transactions for mining not just based on their fees but
  also based on the fees of their ancestors (parents) and descendants
  (children).

Thus, we understand that this is a policy that is implemented by a miner.
Now, the way we can ensure that our stuck transaction falls under this policy is by ensuring our stuck_tx has a child_tx with good fees.

For creating a child raw transaction, we just need the txid from the stuck transaction and new address to send it. Put the funds, the change, what's left is the fee. Sign it and broadcast it.

To determine the right fee and more details check this fee bumping page on bitcoin wiki.


Why are there ETH addresses in bitcoin wallet.dat?

Ethereum addresses are the trailing 20 bytes of keccak256(public_key). In other words, ethereum addresses are any collection of 20 bytes.

0014{20 byte payload} in Bitcoin is the redeem script for a p2sh-p2wpkh address. If you strip the 0014, you're left with 20 bytes. Due to the size of the ethereum address space, the vast majority of 20 byte combinations will lead to unused addresses.


When will the last block halving happen and when will the block reward fall to 0?

I created a Google doc to calculate some metrics of the Bitcoin reward schedule including e.g. the number of halvings, their first blocks, and how much supply is left to be mined.

As you can see, there will be 33 epochs of 210,000 blocks with a block subsidy. Bitcoin doesn't end there, after that the block reward will be composed only of transaction fees.

The block subsidy will be reduced 33 times, 32 times halving the block reward, and the last event ("33rd halving") reducing the block subsidy from 1 satoshi per block to zero satoshis per block. The limit of the block subsidy is accounted in a whole number of satoshis. The protocol does not allow partial satoshis to be created.

The last (32nd) halving will occur on block 6,720,000 reducing the block subsidy from 2 sats to 1 sat, approximately in 2136, the 33rd "halving" will reduce the block subsidy to zero in block 6,930,000 approximately in year 2140. This means that the last block with a block subsidy will be block 6,929,999.

Related:

How many Halving Days will there be?
How many Bitcoin are mined per day?
How much inflation does Bitcoin have, year by year?

Terminology:

Block subsidy: newly minted coins in a block
Block reward: the miner's total yield from a block composed of block subsidy plus transaction fees


Does bitcoin give users credit/debit card. If yes, how do you request the card


Yes, the attacker needs to be faster than the rest of the network combined.  Being faster than the second-fastest miner is not enough.

I think this is where you are mistaken:

  Blocks in the mainchain can only be added sequentially, hence the growth speed of the blockchain is at most the speed of the fastest miner in the network

Yes, blocks are added sequentially, but I can't follow your logic as to why that means block growth only happens at the rate of the fastest miner.  If you are the fastest miner on the network, that in no way means that you are producing 100% of the blocks.  It means that you are producing the highest proportion of the total, which is still likely a minority.  Block growth still happens at a rate of the entire network collectively, regardless of who is fastest.

With that in mind, you can see why an attacker needs to produce blocks faster than the rest of the network combined.


How do you create a scriptsig for a new raw tx?

Okay, turns out my research has led me to answer my own question, mainly from here though it did lack a bit of explanation or didn't explain, I think, as clearly as it could.  So here's my reading/interpretation/translation thereof.  (Go to that page to see the source of my data if need be).

NOTE:  This process may have changed after the addition of "segwit" either in its "lock-in" or its "activation".  I cannot speak to that.

A Quote from that page:

  The final scriptSig contains the signature along with the public key for the source address (1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5). This proves I am allowed to spend these bitcoins, making the transaction valid.

Step 1.  The signature in a given transaction will begin with 473044
(these are standard from what I can see).

Step 2.  Then you must append 0120 to the end of that number to get 4730440120

SIDE NOTE: There are variations upon this which are demonstrated in old transactions and may still exist where you do NOT put that in and you put a different number instead.  I cannot account for and or explain those instances except to say that the "01" designates this as the first integer, and "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).

Step 3. Then you must append the hex value of "r" from the ECDSA signature (which is 2cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713), resulting in:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713

Step 4. Then you append '0220' to the end of the previous code, resulting in
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff7130220

SIDE NOTE: There are exceptions to adding merely "0220" that may exist or have existed in previous transactions throughout the block chain.  The only tool I can give to explaining them is the "02" is in reference to the "second integer" and the "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).  This is just as the "0120" is.  So if there is a third integer I think it would be preceeded by a "03" and if the integer is longer or shorter than 32 bits (or 64 hex alphanumeric characters) then the "20" should be changed to the hex value of half the number of the hex alphanumeric characters.  Just count them, divide by two, then convert decimal to hex to get the correct number to place here, if the need were to arise.

Step 5. Then you must append the "s" value from the ECDSA signature (which I will not get into in this post) which is 6c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82
Resulting in:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82

Step 6. Next you append a '01" which is "SIGHASH_ALL".  I don't know what that really means or fully stands for.

Step 7. Append "41" which is "Pushdata41".  I don't know what the really means or fully stands for.

Step 8. Append "04" to reference the type of public keys you are going to represent for the public key that this transaction is coming from.

NOTE:  "04" is in reference to a particular uncompressed "public key".  Bitcoin usually uses "02" at this point in time.

STEP 9. Append the X value followed by the Y value of the public key, in this case the values are:
14e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee7513
and
10f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd

NOTE:  If you were using a compressed public key, you would only show the first one.

Result:
47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd

I did not go into the S or R creation as I felt that they should be done in a separate post to keep things organized.


How can I move bitcoin-qt blockchain data to bitcoind daemon?

There should be a .bitcoin directory once you install bitcoind on your linux box. Copying those .dat files in this directory should enable bitcoind to read them directly.

Bitcoin-QT is actually using bitcoind under the hood. So it shouldn't be using different structure unless you're using different versions of bitcoind.

Edit: also reading more about bitcoind commands, there's a command to import a file directly. So this should probably be better than directly placing the files in the directory:

bitcoind -loadblock=<file>      Imports blocks from external blk000??.dat file


An eclipse attack is when most (if not all) of your peers are malicious and they basically prevent you from being well-connected to the network to obtain information about transactions you're interested in. An eclipse attack is particular useful when a payer has sent some bitcoins to you in some transaction, then decides to also doublespend the same bitcoins. The doublespender (or payer) will use the eclipse attack to prevent you from knowing that there is also a doublespend transaction out in the open, so you get misled into believing that there's only the original transaction.

A sybil attack on the other hand is where a malicious actor is trying to spam the network with nodes that they control attempting to subvert the network's reputation system. For example, false signalling of support using version bits.

To summarise, an eclipse attack is targeted at a single party; whereas a sybil attack is network targeted. In the context of bitcoin, a sybil attack is not particularly harmful since all nodes operate based on consensus rules and any deviation will lead to said node getting DoS banned.


How does Bitcoin get over the capital controls problem?

Bitcoin is hard, but not impossible, to censor so if governments really wanted to censor bitcoin transactions they could do it. Right now governments seem more interested in wooing bitcoin related businesses to their countries because they see it as something that can contribute to economic growth. But, yes, if they changed their minds they could shut it down.

However, what would happen if they shut it down? Would developers and users just give up? The answer is that we won't. We'll switch to crypto currencies that are even harder to shut down. Crypto currencies with anonymous ledgers like Monero. I don't think governments want that to happen. At least with bitcoin the ledger is transparent.

There is a historical precedent to this. Bitcoin isn't the first attempt to make a digital currency. I suggest you read about digicash and the problems it encountered getting traction. If governments push people will push back!


I'm trying to find out if I invested in bitcoin years ago, how can I find my bitcoin?

If you purchased bitcoin in the past, there are likely only two ways you were storing it.

First, you may have been storing it on some web wallet, where the keys to use the bitcoin are managed for you.  If this is the case, you will likely have registered for the wallet with an email address.  If you think you know which email address this was, and you still have access to it, I recommend searching through your email history.  If the wallet company still exists (and hasn't lost/stolen your money), and you can prove your identity to them, then they could give you access to your bitcoin.

Second, you could have stored the bitcoin in your own wallet.  If this is the case, and you truly don't have your wallet file...you are out of luck.  You probably bought this bitcoin from some company, and again registered with an email, so it doesn't hurt to search for a record of your purchase.  However, if you took on the responsibility of holding onto your keys yourself, and you failed to do so, there is no way to retrieve your money.


Without nodes in a network, there is no network.

In the situation where the 1000 nodes (or even a subset of them) suddenly came back online, the network would simply continue where it left off.

In the situation where all nodes went offline, and all existing data was lost, then the network would begin from scratch with a new blockchain whenever the nodes came back online.

Keep in mind that data loss of the blockchain is highly unlikely.  Since there are so many copies, it would take a fairly catastrophic event to destroy all copies.  In all seriousness, it's more likely that all members of the human race will be destroyed than it is for all copies of the blockchain to be destroyed.  Assuming that a copy exists, the network can always be restarted from one or more backups, and conflicting backups will follow the consensus algorithm to determine which version is more "correct".

Bitcoin is extremely resilient.


Help. Lost my backup phrase, but I have access to my wallet

Depending on the wallet you can usually create a new backup which will give you the same phrase. Look in your wallet for options to create recovery phrase or backup current wallet.


Download of Multibit Windows 64 Bit has corrupt signature

There are various signatures tha you can use to ensure the integrity of your MultiBit downloads.

The 0.5.18 release notes have SHA256 hashes of the binaries:
https://multibit.org/releases/multibit-0.5.18/release.txt

You can check the SHA256 hash of the file you have and it should match.
If it does NOT match then DO NOT USE it.

Try downloading it again from https://multibit.org. It could be that it the download failed.


Why check for multiple nonces despite finding a golden nonce?

There's a difference between what is called a "golden nonce" in the context of the source and a valid block header hash.

To reduce payout variance, miners group into pools and share their income proportionally to their hashpower.

To determine each miner's hashpower, pools use a share system: when you are mining and find a block header of high difficulty (with lots of heading zeroes) but not high enough to be above the current target, you send it to the pool. These difficult-but-not-enough headers are called "shares".

Since finding them is way more frequent than blocks (miners often send several of them per second), no matter how small your hashpower is, it will still be taken in account at payout time even if you're unlucky. The more shares you send, the more hashpower you have, the bigger the share of the pool's income you will get.

They are not broadcast to the bitcoin network, since they would be immediately rejected there and are of no value to anyone but the miner that found them and the pool software.


Public mining pool account w private access

Pools either don't use a password for mining clients, or they use a password different than the one used to log into the website and change things like the cash out address.

So you don't really need to worry about this happening. Just don't choose the same password for mining and website access, if the pool asks you to choose two passwords.

What could happen though is that they change the mining client config to mine for their pool account instead of yours.

There is also the special case of a pool or two that accept the user name as the cash out address. In those cases someone could change where your coins go simply by changing the user name in the client setup, because the user name and cash out address are in this case the same thing.


What prevents hackers from guessing seed phrases?

Nothing.

The problem for the guesser is that 204812 is a very big number (204824 more so).
It is roughly 5,000,000,000,000,000,000,000,000,000,000,000,000,000
Let's say a hundred million different people have Bitcoin wallets and have money.
Lets say a million attackers each guess a million phrases a second.
How long is the average time for the guessers to strike lucky?
Wouldn't that be something like 50,000,000,000,000,000,000 seconds? That's about 1,726,445,291,328 years and the Earth is only 4,543,000,000 years old so that's  380 times the age of the Earth.
Of course, the first guesser might strike lucky with their first guess. But the odds are hugely against them.
Note that the above is not intended to be accurate, just to give a very rough idea of the scales of numbers involved. For example, I haven't looked at how many seed-phrases result in the same seed-number or how many seed-numbers can't be reached from any seed-phrase, I just used a 1:1 correspondence - which is likely wrong.


Is a wallet just a collection of private and public keys?

A wallet can be as simple as just a private key by itself even as software that has access to that can derive the public address from it.  So yes, that data alone can be considered a bitcoin wallet.

But you asked if that is all you need to send and receive so for that you will need software that uses the private key to spend the funds.  Sometimes the term "wallet" is used to refer not to just the data stored but transaction data as well, along with the software that can create transactions and do the accounting for them as well so that you can know your balance.

Proper vocabulary would describe wallet software as being a bitcoin client.  The bitcoin client from Bitcoin.org (also referred to as the "Satoshi" client) does this, and has a local wallet as well.

My Wallet from http://BlockChain.info/wallet is managed through a server, but the wallet itself is stored in your browser.  That type of wallet and client is termed a Javascript-based wallet.  Sometimes the term "hybrid wallet" is used, since to spend using My Wallet you need to use their hosted service where the transaction gets processed.

Another type of wallet is an e-wallet where the wallet data is stored by the service's operator.  An e-wallet can also be referred to as a "hosted wallet".  InstaWallet is one of these.  The just-launched Paytunia is another.  An account at an exchange which hold bitcoins for you is another type of e-wallet service.  Using a hosted wallet incurs risks involving trust extended to the wallet's operator.

But the simplest form of a wallet comes from http://BitAddress.org

It gives exactly what you describe -- a private key and a public address.  This happens to provide one of the most secure wallets as well.  The html source can be copied to a thumb drive and then used to create paper wallets from an "air gapped" system (such as a computer running a secure operating system perhaps using a LiveCD linux distribution) that has no connection to the network and is used for printing out paper wallets.


None that is secure in a decentralized environment. Only PoW is secure.


What is the maximum throughput of the Bitcoin network? (2013)

The current block size limit is 1MB, but this is likely to be changed in the future.

Transactions are about 500B, so the current limit is 2000 transactions per block, or about 3 per second.


Does bitcoind not support txindex=1 option in regtest mode?

If bitcoind stops, them you should have a look in your debug.log file.
Enabling -txindex with an already initialised blockchain (not your first regtest start) requires a reindex.

Either you start with -reindex-chainstate or you delete your <bitcoin-data-dir>/regtest folder


Nobody really knows how it's implemented, other than the developers of the site, but I doubt they keep a single wallet.dat file. They don't store the keys of each address so it could very well be that they don't even use bitcoind.

They could use their own implementation which would allow for better concurrency since they have lots of users accessing their wallets at once.

You can build a bitcoin wallet however you'd like. It doesn't have to be a wallet.dat file. You could even put the information of the transactions in a basic MySQL database (which is good at concurrency) and have something like PHP process and send out the transaction, and you'd have a wallet represented within a MySQL database.

To answer your question, I'm sure of course they do have proper backup routines of their database, just like any other website.


Have there been case studies of how anonymous bitcoins are?

Yes, the most notable one being this one. It illustrates that it is possible to associate transactions and addresses with forum users' identities, as well as connecting them to some organizations (including WikiLeaks, MyBitcoin, Slush's Pool etc).

Tracking users by their IP is a bit harder, although during the work on my master thesis I was able to find an IP address associated with a Bitcoin Address and trace it correctly to the Bitcoin Faucet.


To solve this problem, I restarted bitcoind.

I think that maybe when i was developing my project, I made a bad transaction and it saved in mempool


The build system has changed to autotools in later versions of Litecoin.

The process now looks like this:

./autogen.sh
./configure
make -j4
make install # optional

There's up to date instructions in detail in build-unix.md.


Why my Bitcoin Cash coins moved to another wallet if i did it on original Bitcoin on 12/12/2017?

I see exactly same transaction (moving same sum to same wallet alias
  on same date 12/12/2017) inside Bitcoin Cash blockchain. Can you
  explain me how is it possible?

Bitcoin and BitcoinCash have the same history before August'17


This would be illegal if you didn't inform the user. Things like this also already exist, e.g. https://forum.unity.com/threads/uminer-ethereum-cryptocurrency-miner-inside-unity.499917/


Can a Butterfly Labs Jalapeño be used to mine Zetacoin?

Bitcoin ASICs like the old Butterfly Labs Jalapeno can do one thing and one thing only and that's SHA-256 hashing. Searches indicate Zetacoin uses SHA-256 hashing, so the answer is yes. Whether or not you will make any money is whole different story.


The source code (qtdialogs.py) has this to say about SecurePrint:

  # USE PRINTER MASK TO PREVENT NETWORK DEVICES FROM SEEING PRIVATE KEYS
  # Hardcode salt & IV because they should *never* change.
  # Rainbow tables aren't all that useful here because the user
  # is not creating the password -- it's *essentially* randomized
  # with 64-bits of real entropy. (though, it is deterministic
  # based on the private key, so that printing the backup multiple
  # times will produce the same password).

So it is 64-bit, or ~10^19 combinations. Armory uses a scrypt-based key derivation function for the SecurePrint code. It takes a noticeable amount of time (not long at all, but not seemingly instant) on my computer to calculate the wallet keys/ID from the SecurePrint code. Let's say an attacker has your printout, and it takes 0.1 seconds per attempt. He would need about 58 billion CPU years to find the right private key by guessing the SecurePrint code. So yes, it would appear that it is secure enough to disperse paper backups, as long as you're not going to have an extremely valuable (e.g. billions of dollars) wallet.

You might consider whether scrypt ASICs (which will come in some form, unless Litecoin and its kin die off) can attack your key as well. I wouldn't expect it to be faster by a factor of 500 billion (which would put the time down near a month), but if you consider this to be a "lifetime wallet", you might not want to have this as a potential weakest link.

Warning: I'm not an expert in Armory, just some guy who took a look at the code and knows a bit about cryptography. If you decide to post your SecurePrint-secured paper wallet all over the Internet and someone steals your bitcoins, don't come crying to me.


Http is a protocol that works on TCP.
So if you have an http-server, it uses TCP to communicate anyway.
The better question would be "Why should they use an http-server if they don't need it?".

They don't need/want to show a website. They just want to send binary information easily and want to be sure that the other peer received it completly/correctly. And TCP is the perfect protocol for that.


It is absolutely possible - but not necessarily feasible - for an attack to branch off in the past, and create a new majority chain from that.

However, it effectively means that you or the miners who are participating in this attack need to mine faster than the rest of the network combined. Otherwise, you'll never be able to 'outrun' them, and the further back you start, the less likely it is you'll ever catch up.

For this reason, this is also called a 51% attack. For anything further back than a few blocks, you almost certainly need a majority of the hashrate to succeed.


Can I estimate time to confirm based on the number of existing transactions awaiting confirmation?

This is an impossible question to answer, because there will likely be new transactions added to the mempool continuously.

If more transactions get confirmed than are added, the mempool will shrink in size, and lower fee txs will confirm.
If less transactions get confirmed than are added, the mempool will grow in size, and it is likely that higher fee txs will confirm.

As a user, the total number of transactions shouldn't be of concern to you, instead you should look at what the fee rates of currently confirming transactions are, and plan accordingly. If your tx needs to be confirmed ASAP, you should set a fee slightly higher than what you are currently seeing. If you can afford to wait, you can set the fee lower, and hope that the mempool will shrink in size (but this is fundamentally unpredictable, it depends on the actions of all other useres).

Ultimately, you'll really only care about the number of txs paying a higher rate than you are willing to. Those txs are the ones that will affect how long your tx takes to confirm.


I can't say I'm familiar with all of the cryptocurrencies you mentioned, but the Bitcoin clones generally use elliptic curve (secp256k1) cryptography and the same address generation scheme.

Keys

A private key is any 256 bit number. However, for the EC used by Bitcoin, it must be between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140. Any random number in that range is valid.

A public key is calculated from the private key using the elliptic curve algorithm with the secp256k1 parameters, which is a one-way deterministic algorithm.

BIP32 is a standard Bitcoin proposed for key generation so a hierarchy of keys can be derived using a set of indices. This is to be implemented by wallet software to make it easier to generate a set of keys deterministically and restore them if needed from a single master key and set of indices. It is not required to follow BIP32 to generate a valid key pair.

Addresses

See Address, Technical background of version 1 Bitcoin addresses, and List of address prefixes.

Also, I wrote this article explaining Bitcoin address generation step by step, which might be helpful: https://medium.com/coinmonks/how-to-generate-a-bitcoin-address-step-by-step-9d7fcbf1ad0b


How to get senders address with bitcoinj (no duplicate)?

For future reference:
In bitcoinJ (java version) the input/output addresses of transactions are located in TransactionInput and TransactionOutput objects.

For example: for Transaction tx:

List<TransactionInput> inputs = tx.getInputs();
List<TransactionOutput> outputs = tx.getOutputs();

for(TransactionOutput out : outputs){
    System.out.println(out.getAddressFromP2PKHScript(params));
    System.out.println(out.getAddressFromP2SH(params));
}

for(TransactionInput in : inputs){
    System.out.println(in.getFromAddress());
}

Keep in mind that some transactions might not have an input address.
Here is the github description of getFromAddress() method:

  Convenience method that returns the from address of this input by parsing the scriptSig. The concept of a "from address" is not well defined in Bitcoin and you should not assume that senders of a transaction can actually receive coins on the same address they used to sign (e.g. this is not true for shared wallets).


Keeping a portable long-term offline wallet

All wallets basically just store public+private keys. If you store those keys, it's fine.

Also, there's the normal wallet file, which is stored in the Berkeley DB format, which is an extremely common format and it has been for the past 15+ years. While I can't speak with 100% certainty, I'd say that the wallet.dat file from the reference client is a pretty safe bet (perhaps even safer than storing the raw keys).

Which software can export/import it? Well, there may be a few exceptions, but almost all Bitcoin wallets, either online or offline, can handle those files.


Difficulty is a multiple of the minimum amount of Proof of Work (PoW) any valid block can contain.  In Bitcoin, the minimum difficulty (called difficulty 1) is defined in the code by this byte mask:

consensus.powLimit = uint256S("00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff");

That is, a hash must start[*] with 8 hexadecimal zeros.  That's 4 zero bytes, or 32 zero bits.

If you double that difficulty, that's difficulty 2.  Double it again and it's difficulty 4, then 8, then 16.  At difficulty 16, the hash must have at least 8 + 1 = 9 zeros.  Double it again and it's 32, then 64, then 128, then 256.  At difficulty 256, the hash must have a minimum of 8 + 2 zeros.  Et cetra...

As I write this, the current difficulty is 4306949573981.513.  We can see how many minimum zeros that corresponds to by taking its binary log, dividing by the 4 bits that are in in half a byte (one hexadecimal character) and adding the eight zeros from the minimum difficulty:

log2(4306949573981.513) / 4 + 8
= 18.49245089279219

For comparison, here's the most recent block header hash (reformatted into byte pairs for readability).  It has 18 zeros, as expected.  (Note: if you do this experiment at home, note that the hashes are always allowed to have more zeros; they just can't have less.)

0000 0000 0000 0000 0023 bfeb 3a02 1b25 7577 9256 7762 275e b72a d88b 7d50 d7f7

[*] Bitcoin is weird.  We display hashes backwards from most other software, so the zeros that start a block header hash are actually at end if you use any non-Bitcoin software to do the hashing.


Differences between MemoryBlockStore and SPVBlockStore

MemoryBlockStore keeps StoredBlocks in memory and it is used primarily for unit testing.

Whereas SPVBlockStore holds a limited number of block headers in a memory mapped ring buffer. With such a store, you may not be able to process very deep re-orgs and could be disconnected from the chain (requiring a replay), but as they are virtually unheard of this is not a significant risk.
You can find the reference document from the following link:

MemoryBlockStore
https://bitcoinj.github.io/javadoc/0.12/org/bitcoinj/store/MemoryBlockStore.html

SPVBlockStore
https://bitcoinj.github.io/javadoc/0.12/org/bitcoinj/store/SPVBlockStore.html


Why isn't the price of BTC rapidly growing due to WannaCry?

I've read somewhere that around $6000 had been paid in total; at roughly $500 per ransom that's 12 people who actually paid. That's a speck in the ocean.


What can be done to slow/prevent mining centralization?

Asking how to prevent the mining industry from being centralized into places with low electricity costs is like asking how to prevent the shipping industry from being centralized into cities that are on the coast.  Both industries will tend to thrive in places where the profit margins are highest...and there's no profit margin in building a port in a land-locked city.

Since we are assuming that access to the latest ASICs is uniform for all contenders, profit margins are determined by electricity costs.  However, remember that running the ASICs isn't the only thing that miners do that costs electricity.  Cooling the ASICs is probably the larger electricity cost, just like it is in most data centers.  Given two locations with the exact same electricity cost, but different average temperatures, the location with the colder temperature would prove to be more profitable.  It would cost less electricity to cool the ASICs.

Now the problem seems to be mining centralizing into locations that have both low electricity costs and low temperatures.  However, the second factor does create a variation in the trend.  There are some locations that may have higher electricity, but are so cold that they don't have to use that much of it to cool the ASICs.  There are other places that may be warm, but have such low electricity costs that it doesn't matter.

I'm fairly sure your question doesn't have a simple answer, but be reassured to know that there is at least another factor that will affect the trend.


Importing a private key should not cause you to lose your wallet. If you import a private key and then restore from a previous backup, you may lose that key, however.


What if the system crashes if I have made transactions after my backup?

Assuming you had a chance to send those transaction out, they will still be processed. So long as the transactions didn't create any new change addresses, your wallet will still have all the information needed to spend any Bitcoins you have left.


The blockchain is the complete transactional history of Bitcoin. It collects every transaction performed in blocks which each are linked to their predecessor block.

By parsing the complete blockchain, you can discover all unspent balances. These are usually tied to addresses, which represent users much like email addresses do.

Also see these two related questions:

What is the “blockchain”?
Can someone explain how the Bitcoin Blockchain works?


Is buying BTC on localbitcoins.com safe?

It's a reputable website, but it's really up to the person you are buying from.

Do your research, choose a person with good reputation, make sure you understand how the escrow system works, and under no circumstances release escrow early.


Can bitcoins be exchanged for nonlicensed "Professional" services?

Persons can dispense all sorts of professional services as long as they aren't for "business" or "pay"

In some places, yes. In other places, no. Since you didn't specify your jurisdiction, I will guess that you live in Alabama. Alabama Code - Section 34-3-6 (b) defines the practice of law this way:

Whoever,
(1) In a representative capacity appears as an advocate or draws papers, pleadings or documents, or performs any act in connection with proceedings pending or prospective before a court or a body, board, committee, commission or officer constituted by law or having authority to take evidence in or settle or determine controversies in the exercise of the judicial power of the state or any subdivision thereof; or
(2) For a consideration, reward or pecuniary benefit, present or anticipated, direct or indirect, advises or counsels another as to secular law, [...] or
[2 lines snipped.]

For example, if you help your neighbor write up their will, and you weren't a licensed lawyer, you could potentially be in violation of this section, even if you never received any money.

Hypothetically, if neighborA were to dispense Legal Advice for PAY, yet NOT be a licensed attorney, then they'd be involved in an illegal operation according to political regulations. [...] can these folks legally receive bitcoins? Or, is that considered Pay and Business?

Well, the IRS thinks that Bitcoins are money. Various state-level tax agencies think that Bitcoins are money. I'd guess that Bitcoins received for legal advice would probably be considered 'pay.'
As for dispensing medical advice...

Van Thiel claimed he performed abortions, removed sebaceous cysts, treated sexually transmitted and life-threatening diseases and provided ozone treatments at “unbeatable prices” in exchange for Bitcoins, gold and silver and firearms.

There has been someone who was prosecuted for unlicensed practice of medicine in exchange for Bitcoin.


Standardness rules related to BIP 16 (P2SH)

In general, changes to policy rules are not specified in BIPs. They're up to individual clients anyway.

BIP16 is not obsolete, though its description of the standardness rules in Bitcoin Core is outdated by now. However, its consensus rules (i.e., what is valid in a block, not what will be relayed as individual transactions) are unmodified since it activated in 2012 — anything else would be a hard fork.

As far as policy in Bitcoin Core goes, in version 0.10.0 (2014), relaxed standardness for P2SH spends, allowing any script using up to 15 signature checks. Several later changes to standardness were made (including every script-affected softfork (CLTV, CSV, Segwit) was accompanied with making corresponding spends standard), but none so fundamental.

Today (Bitcoin Core v0.19.0) standardness rules for P2SH spends include:

Max scriptSig size is 1650 bytes including redeemScript (not enforced on testnet)
Max 15 signature checks in the script (not enforced on testnet)
No opcodes intended for future upgrades (NOP3-NOP10) [discourage upgradable nops rule]
No non-DER encoded signatures, or hybrid public keys [strictenc rule]
No signatures with s values in the upper half of the range [low-s rule]
The additional argument popped by OP_CHECKMULTISIG(VERIFY) must be exactly the empty byte array (as pushed by OP_0) [nulldummy rule]
All pushes must use the minimal size encoding (OP_i instead of direct pushes where available, no OP_PUSHDATAi when unnecessary), integers can't have unnecessary zero padding [minimaldata rule]
Execution must end with exactly one non-zero element on the stack [cleanstack rule]
Checksig operations that fail must be passed an empty signature [nullfail rule]
OP_CODESEPARATOR cannot be used (not even in an unexecuted branch).
Signatures that are verified cannot appear in the scriptPubKey (they must come from the scriptSig) [const scriptcode rule]
At the transaction level: no tx version above 2, and the whole tx cannot be larger than 400000 weight units (100000 bytes if no segwit inputs are present).


What happens to a node if .bitcoin/chainstate is corrupted?

I found an answer by Pieter Wuille to another question that seems to be relevant here. The relevant part states:

  "Please don't go download a chainstate from a random place on the Internet though. They can introduce arbitrarily many coins assigned to themselves, and your client would accept them. If many people started running nodes using the same chainstate 'copy' such transactions could even get into blocks, and cause forks in the best case, and theft in the worst case."

So, this seems to indicate that a node will simply not realize that its chainstate is modified.


How will the Ledger Half Custodian SegWit2x coin split work?

Relevant info in this answer: https://bitcoin.stackexchange.com/a/62134/51948

A tainted input is referring to an input which is only valid on one chain, not both. Such an input can be created by mixing some coins which were mined after the fork in, making the transaction and all its children invalid on the other fork, and thus allowing those transactions to be further used for splitting other coins too.

It sounds like the "contract enforced by the new application" just means that the ledger application will only sign transactions which send their inputs back to themselves, it isn't just going to let you spend their inputs as well and give you free coins.


Who is paying for the running costs of Bitcoin?

The people operating the mining hardware do. Mining hardware consumes electricity, so people who run the hardware receive an electricity bill from their electricity provider. They pay the bill using the proceeds from mining. Usually miners will sell some portion of the Bitcoin they earn for fiat, and pay for electricity using that fiat.


Could any one show me how to get pubkey in Bitcoin Core?

Try:

$ bitcoin-cli getaddressinfo '<your address>'

{
  "address" : "address",        (string) The bitcoin address validated
  "scriptPubKey" : "hex",       (string) The hex-encoded scriptPubKey generated by the address
  "ismine" : true|false,        (boolean) If the address is yours or not
  "iswatchonly" : true|false,   (boolean) If the address is watchonly
  "solvable" : true|false,      (boolean) Whether we know how to spend coins sent to this address, ignoring the possible lack of private keys
  "desc" : "desc",            (string, optional) A descriptor for spending coins sent to this address (only when solvable)
  "isscript" : true|false,      (boolean) If the key is a script
  "ischange" : true|false,      (boolean) If the address was used for change output
  "iswitness" : true|false,     (boolean) If the address is a witness address
  "witness_version" : version   (numeric, optional) The version number of the witness program
  "witness_program" : "hex"     (string, optional) The hex value of the witness program
  "script" : "type"             (string, optional) The output script type. Only if "isscript" is true and the redeemscript is known. Possible types: nonstandard, pubkey, pubkeyhash, scripthash, multisig, nulldata, witness_v0_keyhash, witness_v0_scripthash, witness_unknown
  "hex" : "hex",                (string, optional) The redeemscript for the p2sh address
  "pubkeys"                     (string, optional) Array of pubkeys associated with the known redeemscript (only if "script" is "multisig")
    [
      "pubkey"
      ,...
    ]
  "sigsrequired" : xxxxx        (numeric, optional) Number of signatures required to spend multisig output (only if "script" is "multisig")
  "pubkey" : "publickeyhex",    (string, optional) The hex value of the raw public key, for single-key addresses (possibly embedded in P2SH or P2WSH)
  "embedded" : {...},           (object, optional) Information about the address embedded in P2SH or P2WSH, if relevant and known. It includes all getaddressinfo output fields for the embedded address, excluding metadata ("timestamp", "hdkeypath", "hdseedid") and relation to the wallet ("ismine", "iswatchonly").
  "iscompressed" : true|false,  (boolean, optional) If the pubkey is compressed
  "label" :  "label"         (string) The label associated with the address, "" is the default label
  "timestamp" : timestamp,      (number, optional) The creation time of the key if available in seconds since epoch (Jan 1 1970 GMT)
  "hdkeypath" : "keypath"       (string, optional) The HD keypath if the key is HD and available
  "hdseedid" : "<hash160>"      (string, optional) The Hash160 of the HD seed
  "hdmasterfingerprint" : "<hash160>" (string, optional) The fingperint of the master key.
  "labels"                      (object) Array of labels associated with the address.
    [
      { (json object of label data)
        "name": "labelname" (string) The label
        "purpose": "string" (string) Purpose of address ("send" for sending address, "receive" for receiving address)
      },...
    ]
}

See https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/getaddressinfo/


How to determine the geographic distribution of the hashrate?

While blockchain.info provides a hashrate distribution, it is aggregated at the pool level while I would like to know more about how the hashrate is distributed among the pools' servers.

That is not possible to ascertain with certainty. When a Bitcoin block is mined, there is no way to determine which node/pool mined it. Block explorer sites like blockchain.info look at the coinbase data in coinbase transaction to possibly link the block to a particular pool. For example, if you look at the last mined block 594,041 the coinbase transaction has the coinbase data as:

037910091a4d696e656420627920416e74506f6f6c39331400332020d34beafabe6d6d38d664d05278d5312fc43b4a47d259012d94db2c113f41e0ee36a6711161138004000000000000006cbf008036030000

The first byte 0x03 indicates to push the next three bytes on to the stack. Then bytes 0x791009 indicate the block height (594041 in this case) in little-endian. Then if you look at the bytes 0x4d696e656420627920416e74506f6f6c it represents "'Mined by AntPool" in ASCII. This is what the explorers use to say that the block was actually mined by Ant Pool. Nothing prevents me from mining a block tomorrow with the coinbase data that points to a particular pool when in reality it has nothing to do with them. The block explorer sites will use this false data to show on their websites that the block was actually mined by that pool name that I sneaked in.

  Several aggregator websites, including blockchain.info, maintain low-latency connections to a thousands of nodes and record the IP address of the first connected node to relay each block

This data is also unreliable. I can run VPN, mine a block and relay it to the network with an IP address located thousand of kilometers away from my actual location. Moreover, you can run Bitcoin full node on tor which would completely obfuscate your identity.


A deanonymizing dust attack works by sending dust to large amounts of addresses. The assumption is that when people send transactions/perform consolidations in the future, dust from multiple addresses will be grouped into a single transaction, thus revealing many addresses controlled by a single entity, since the dust would be swept in a single tx.

(this is somewhat of a simplification, since most parties interested in performing such attacks will also be using other data to group together multiple independent txs).

The best way to prevent against this attack is to:

Never spend dust in a transaction that consumes inputs from addresses that have not previously been linked by a transaction.
Don't spend dust at all.

This will lead to some utxo bloat, but if you are reusing your addresses, you can spend the dust when spending another utxo from the same address. If you are not reusing addresses, simply never spend it.

Some wallets, such as the Samourai Wallet (no affiliation), provide an option to mark dust as unspendable. For systems that you build, you will have to ignore such outputs yourself.


Only one chain is appearing in Miner Status on Antminer S9

Is there a possibility one of your power-supplies have gone bad? You can further debug this by obtaining the "Kernel log" found on the "System" tab. I would also try re-seating the cables, and test each hashboard individually (power them one at a time to determine if they are still OK -- make sure to shutdown/unplug your miner before performing any work!)

If you can provide that file, more information should be available.


How to get pending balance in with bitcoinj?

Edit: I don't think there's a method to do that, but this should do the same thing:

// calculate balance, only include transactions that are not in a block
List<TransactionOutput> candidates = wallet.calculateAllSpendCandidates(false, false);
Coin value = Coin.ZERO;
for (TransactionOutput out : candidates) {
    if(out.getParentTransaction().getAppearsInHashes() == null) {
        // Not seen in any block that we know of
        value = value.add(out.getValue());
    }
}


What incentive is there for a miner to not cancel his own 'real' txs

It is a short term gain only, as bitcoin would very quickly lose its value as people realize that holding one's wealth in bitcoin has become a bad idea. Behaving honestly gets you income until such a time your hashing power decreases.


The reason you are getting a different address is because you are appending the same checksum that you got from using the 03 prefix to the new prefix + payload. You need to double hash the new prefix + payload and then append the first four bytes and then encode it in base58.

If I decode your result MANDhrctLRAygo3dFckfWvEaWeQiti143C to hexadecimal, I get 321b0e61ac671bde7fb52e2f3d6e2dc213609d9de5020cb31b. In this hexadecimal string, your prefix is 32, payload is 1b0e61ac671bde7fb52e2f3d6e2dc213609d9de5, and checksum is 020cb31b.

The checksum that you would get after double hashing the new prefix + payload is e29f4248. So, you should base58 encode 321b0e61ac671bde7fb52e2f3d6e2dc213609d9de5e29f4248


How to use two-factor authentication at btc-e?

it was easy to set up for me using an android phone ... just install the google auth, scan the code they give you on btc

new users should take a screen shot of the QR code and print it out and save in secure location.  You can't get back to that QR code, so save it from the beginning.

Here is a more general info on the topic:

http://cadince.com/3-ways-to-move-google-authenticator/


Is Hashgraph a serious competitor for the blockchain?

The Hashgraph consensus mechanism achieves Byzantine Fault Tolerance (BFT) using voting on a braided tree of hashed events (the "hashgraph") that is faster and more lightweight than Nakamoto consensus on blockchain using Proof of Work (PoW). However, it is being positioned for different use cases than cryptocurrency.  Whether its consensus mechanism is better PoW really depends on the use case. Hashgraph actually layers nicely on top of blockchain, e.g., by using Bitcoin for Proof of Stake or Proof of Burn. That said, it will certainly be more suitable than blockchain for many commercial applications that need distributed shared memory and high transactions per second on consumer grade nodes.

In addition to the consensus algorithm, when comparing the two it also makes sense to consider the full range of features that would be supported by a bonafide cryptocurrency platform, which for Bitcoin would mean duplicating the features in its proposed payment platform, Lightning. Is it Hashgraph's express goal to replace Bitcoin+Lightning?  Clearly not at this time. Can it? That is not yet clear, and whether it can will be determined as much by additional factors including licensing and developer community support as by the consensus algorithm. Lightning will support blockchain contracts, bidirectional payment transactions and payment routing. Hashgraph could conceivably be used to implement the off-chain transaction ledgers, though that could require dozens and possibly up to thousands of such Hashgraph ledgers to satisfy the millions to billions of transactions per second that Lightning is targeting.

I hope that helps, best of luck to you.


Is it true that only UTXOs can be used as Transaction Inputs?

This question makes no sense.

Of course you can make an invalid transaction that doesn't spend an unspent output. If you're fine with calling invalid things transactions, I could just take a piece of random data and call it a transaction.

A valid transaction can only spend unspent outputs.


echo -n  "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6"
| sha256sum

Gives: 32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce

echo "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6"
| xxd -r -p /proc/self/fd/0 | sha256sum

Gives: 600ffe422b4e00731a59557a5cca46cc183944191006324a447bdb2d98d4b408

Conclusion: You hashed an ASCII representation of the public key in hexadecimal rather than the public key itself.


Things are worth what people are willing to trade for them. The same is true for Bitcoin. Its value is insured by nothing other then what people will trade for it.

There are some distinctions between  bitcoin and other currencies which are worth noting.

Bitcoin has no intrinsic value. While this is true of many modern currencies such as the U.S dollar, it has not always been the case, such as when the U.S. was still on the gold standard. (Gold has some intrinsic value such as its use in circuitry )
New Bitcoins get created by an algorithm which closely follows a geometric series as opposed to a central authority, such as the Federal Reserve.

This second point while having some benefit has proved to be significant shortcoming for Bitcoin. In most currencies, as the volume and rate of transactions increases, so to does the amount of currency. This is not the case for bitcoin, and it has led to severe  hyperinflation. This is a bad thing for a currency, because if you use it as your yardstick of value (which currencies are) of other goods and services, then everything else's value is constantly being depreciated.

In short, Bitcoins economy dosent work all that well. Its based on speculation, and its only (as far as I can tell) real value as a medium of exchange comes from the drug market silk road, which uses it exclusively.


Market price is market price, which is what people are willing to pay for it.  You can pick any market out there (mtgox, bitstamp, etc).  No different to the price of gold, if you wish.

Although an average price across multiple exchanges might be useful in a theoretical sense, the reality is that when you come to sell you will sell in a single exchange at a single price.  Added to that the exchange rate of BTCxUSD is fluctuating so rapidly right now that attempting to use it to calculate what you might obtain even a week from now is probably not a sound basis on which to generate a financial calculation.

If you want to work out if mining for coins is worth it, then the general answer is "no".  A more detailed answer can be found by using a mining calculator

Until now, it has has always been the case that purchasing bitcoins is a wiser way of spending your money than putting it in to hardware or even power to generate your own.  Unless you're buying an ASIC-based miner I would suggest that this is the best way to approach bitcoins right now.


When you place an order to sell LTC in btc-e it checks if there is an order to buy LTC at the same rate as you specified. If there is order to buy LTC at the same rate as you specified in your sell order it will fill your sell order up to the amount of the buy order. If the buy order amount is bigger than your sell order your sell order will be filled instantly and you will receive BTC and the buyer will receive your LTC. If there is no buy order at the rate you specified the system will wait for someone to buy LTC at the same rate. You can always cancel these orders before they are completely filled, but remember the 0.20% trading fee is taken when you place an order and not when you complete the order.


How to connect the Blockchain to the Network without IP Address?

The bitcoin client has many means to discover other ip in the bitcoin network, in the case of DNS request, which will return many ip address each times, here are the diferent DNS used as in 2017:

  seed.bitcoin.sipa.be dnsseed.bluematt.me dnsseed.bitcoin.dashjr.org
  seed.bitcoinstats.com seed.bitcoin.jonasschnelli.ch
  seed.btc.petertodd.org

You can see all the methods used by the bitcoin client to discover nodes here: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery


Can we sign a psbt raw tx having multiple inputs created from BTC node with bitcoinjs lib?


What is the safest medium on which to store my wallet/private keys?

Print out your private keys to a Paper Wallet and print the keys on Archival Quality Paper. Those should last until the year 2211. They are however un-encrypted so you should store them in a bank safety-deposit-box or somewhere just as safe.


Bitcoind walletnotify runs only when transaction get it's first confirmation

You are in blocks only mode as you have blocksonly=1 set in your bitcoin.conf. This means that your node will not receive or relay unconfirmed transactions. You only see blocks and the transactions that come in blocks. Thus the first time your node will see an incoming transaction is when it is first included in a block.


The public network would see only that a transaction occurred - that a large amount of Bitcoin was transferred from one address (or set of addresses) to another.  There wouldn't be any way to be sure, from that information alone, that the transaction was actually a sale, rather than the same owner just moving the coins to a different address (e.g. for cold storage).  One also couldn't necessarily know who the owner or recipient of the coins was.  If the coins were spread across many addresses, you couldn't even be sure they all belonged to the same person.

So I'd say that statement is false.


Processing bitcoins on my website completely by myself, with no third-party bitcoin SaaS services

First, Electrum relies on Electrum servers, which are essentially a third party SaaS for SPV proofs. It's a fine thing to use for most people and as long as you aren't concerned that the server may compromise your privacy, you should be fine. But that said, you can say that about any SaaS service, so Electrum is probably not the solution you're looking for.

If you want to do everything yourself, you will have to run a full node at a minimum. You can create a wallet using a library like pycoin (https://github.com/richardkiss/pycoin) but that's much more work than using a full-node wallet like Armory.

There's actually webshop code written for processing bitcoin payments yourself (https://github.com/goatpig/BitcoinArmory/tree/master/webshop). The main benefit here is that only the public key is on the server so even if you get hacked, your bitcoins can't move without your say-so. Full disclosure: I wrote that code.

Another option may be using bitcoind, but that will require you to keep your private key on the server (NOT A GOOD IDEA).


is the proof-of-work for safety or efficiency?

In principle, yes, what you suggest could work, even in your "extreme case".  But in practice, if it took very little work to create a valid block, then there would be trillions of blocks created per second (by both good and bad actors), and it would become impossible simply to store or transfer that much data, not to mention trying to sort them into a chain.  You'd also have a lot more people stepping on each other's toes by creating multiple blocks naming the same parent, leading to many forks in the blockchain that would take a while to be resolved.

But there would be nothing wrong with altering the difficulty schedule so that blocks get created at a somewhat higher average rate (note that the Bitcoin standard is 0.1 blocks per minute, i.e. one block every 10 minutes, not 10 blocks per minute).  The choice of 0.1 blocks per minute was arbitrary and a different rate would work fine.  Litecoin, for instance, uses a rate of 0.5 blocks per minute.

It is helpful not to have it too fast, so that most of the time there is at least a few seconds between blocks, and the block has a chance to propagate through the network before a new one is found.  Otherwise you get more forks, as mentioned above.

Also note that a common misconception is that reducing the block time would speed up confirmation of transactions.  The security of a transaction against double-spend is related to the total work done on top of it in the blockchain, not just the number of blocks.  So if Bitcoin increased the block rate to 0.5 per minute like Litecoin, that would mean each block demonstrates only 1/5 as much work as before.  To get equivalent security to the current standard of 6 confirmations, you would now have to wait for 30 confirmations, and it would still take 60 minutes.

So while there wouldn't be any particular problem with increasing the block rate (other than those inherent in changing the protocol through a hard fork), there wouldn't be any dramatic benefits either.