What's the minimum setup to mine a block alone?

In hopes of making this a useful answer in the long run, I will show how one can answer this question in general, then give an example using today's values.

Let d be the current Bitcoin difficulty, which can be found, for example, with the getdifficulty command in Bitcoin Core, or from any of a number of sites by searching Google for "bitcoin difficulty".  The average number of hashes needed to mine one block is then h = 232d.

Suppose you have mining equipment with a total hash rate of r hashes per second.  The time M needed to mine one block is of course random.  Since each hash is effectively an independent trial of mining a block, all of which have the same very small probability of success, and those trials are executed very rapidly, the distribution of M is well approximated by an exponential distribution with rate r/h Hz.  As such, the probability p of mining at least one block within some fixed time t seconds is p = P(M < t) = 1 − e−tr/h.  If you choose values for t and p, you can solve for r to determine what hash rate you would need to have probability p of mining a block within t seconds.

You can then look at a page such as https://en.bitcoin.it/wiki/Mining_hardware_comparison which lists the hash rate of various mining hardware, and decide how many units of your favorite miner you would need to achieve that hash rate.

As an example, suppose you want a 50% chance of mining a block within 30 days. As of right now the difficulty level is d =  39 603 666 252. Taking p = 1/2 and t = 60*60*24*30 = 2 592 000, you find

  r = 45 486 834 753 298

or about 45 Thash/sec.  Let us suppose you wanted to standardize on the ASICMiner BE Prisma, which, according to the page linked above, generates 1.4 THash/sec, draws 1.1 kW of electrical power, and costs US $600.  You would need roughly 32 such devices, at a total cost of US $19 200.  You would use 35.2 kW of electricity.  (By contrast, electricity service to single family homes in the US is often a maximum of 24 kW (100 A at 240 V).)  At a typical electricity cost of US $0.10 per kWh, that would cost you US $3.50 per hour, or US $2 520 per month.

This assumes that the mining difficulty does not increase significantly over the course of the month, which is not a good assumption (it typically increases every 14 days or so).  The expected mining rewards from this setup would continue to decrease as the difficulty increases over time.


How likely are key pair collision attacks?

I am not asking because I want to do this, rather I want to understand what mitigates this threat vector. I understand the total number of key pairs is massive, but it seems like someone could build a collision farm to hammer out key pairs.

Someone could, but because the total number of key pairs is massive, there would be no point. They could instead build a mining farm or put their money in interest bearing securities and have a probability of making a profit several trillion times higher.

Let's look at the probability of them making at least a single Bitcoin. At most, 21 million accounts can contain one Bitcoin or more. So they have to find one of 21 million key hashes out of 2^160 possible hashes. Let's assume their farm includes a billion cores, each of which can try 2 billion keys per second. In one hundred years, their probability of success would be approximately one in a ten billion billion.

So for a one in ten billion billion chance of making one bitcoin in a hundred years, they'd need a billion cores, each of which is trying two billion keys per second. Seems like they'd find something else to do with their time, doesn't it?


Ruby: How do I create a wallet and import an electrum seed using money-tree gem

Create a new wallet in Electrum.  Copy the 'Master Public Key' and pass it to the money-tree gem like this:

require 'money-tree'

@node = MoneyTree::Node.from_bip32("YOUR_MASTER_PUBLIC_KEY")

i = 0
20.times do
  @child = @node.node_for_path "m/0/#{i}"
  puts @child.to_address
  i+= 1
end

This will give you the first 20 child nodes of the first child of the master public key.  These addresses should be the same as your "Receiving" addresses in your Electrum wallet.


How doesn't the most powerful miner get the block reward everytime?

You need to build a valid block. That means that you need a valid nonce. If you start searching from 0, 1, 2, 3... or wheather you try random numbers is irrelevant.

The hash is also not only dependant from the nonce. If you start at 0 and another miner starts at 0 and you both have a different set of transactions in the block, you need to finde different nonces.


Once a client has the template it can modify it to make the header different, giving you a new nonce range to search. In modern miners this happens thousands or tens of thousands of times a second.

The timestamp in the header can be updated if needed, this is known in old software as nRollTime. This method is generally not used anymore because you only get one new range per second.
The "extraNonce" can be updated, the random data in the coinbase transaction is altered and the merkle tree is re-hashed up to the root, which changes the header. This technique is used by Stratum miners as well.
Transactions can be added or removed from the tree.

GBT and Stratum are distinct from an old system called GetWork which simply gave out just a partially hashed header, every time the nonce range was exhausted the client would need to make a new request to the server they were mining from. This is what your quote is alluding to.


What prevents similar time-warp attacks in Bitcoin as happened to Verge?

Nothing directly prevents it in Bitcoin, and indeed the attack has been demonstrated on testnet3 many times---it's the primary reason that testnet3 currently has almost three times as many blocks as Bitcoin, despite being launched several years after Bitcoin mainnet and with a something similar to[1] Bitcoin's 10-minute average block interval.

Indirectly, there are several reasons the time warp attack is less practical on Bitcoin mainnet than testnet3 or altcoins like Verge:

Obvious: once blocks used in a time-warp attack are broadcast, anyone can see that median-time-past (the monotonic clock in Bitcoin) is lagging far behind real time.
Slow: the time warp attack exploits the formula used for retargeting, but retargeting only runs once every 2,016 blocks (two weeks at normal rate) and can only reduce difficulty by a maximum of 75% per period.  Now, 75% is a lot, but so is spending two weeks executing a publicly-visible attack.  Further difficulty decreases can be executed faster due to the modified difficulty, but they're still pretty slow: 3.5 days for the second retarget; about 1 day for the third; about 6 hours for the fourth; etc...
Easily fixable by miners: if honest miners control the majority of the hashrate, they can simply refuse to build on top of blocks whose timestamps are too far in the past.  If median-time-past is restored to its normal trailing average before the end of the initial 2,016-block retarget period, difficulty won't be changed any more than normal.

If all these reasons do indeed provide indirect mitigation, then why do we see the attack on testnet3 every few months?  Mainly because testnet3 uses the same SHA256d proof of work function as Bitcoin and so anyone who wants to mine blocks really quick can hook up some modern ASIC miners to create a bunch of testnet blocks quickly.  This would normally rapidly increase difficulty, but the increase is prevented using the time warp attack.  That said, in at least one case in the past where a time warp attacker made testnet3 unusable for an extended amount of time, some generous person pointed their own huge mining rig at testnet3 to overwhelm the attacker and bring difficulty back up.

On Bitcoin mainnet, if the attack was ever executed, I think the story would be different.  Within days, a large percentage of the userbase would know the attack was ramping up and would start to pressure honest miners to reject the attacker's blocks.  I personally expect miners would comply (as the next step would be for people to start throwing around phrases like "PoW function change"), which would defeat the attacker and cost him expected revenue for every rejected block.

If attackers expect the scenario would play out basically the same way I think it would, then there's no point in them starting the attack in the first place---which I think is what ultimately prevents time warp attacks on Bitcoin.

[1] Testnet3, unlike Bitcoin, has a rule that if no block has been mined within 20 minutes (according to block header time), that a miner can create a difficulty-1 block (the lowest difficulty).  That means that even completely honest mining on testnet3 is faster than on mainnet, as on mainnet something like 20% of blocks take longer than 20 minutes to find.

Some extra notes:

A fork could change the retarget calculation to use median-time-past instead of raw block header time.  This could fix the time warp attack on Bitcoin, but it would probably have to be a hard fork.
Since the BIP113 soft fork, median-time-past has been used to restrict which nLockTime transactions miners can include in their blocks.  Not many transactions use nLockTime with a time at present, but if there was a time warp attack, users could start doing so to create a large fee incentive for miners to bring median-time-past closer to real time.


Nowadays, there are custom miners for Bitcoin. These use customised hardware (ASICs) and thus GPU mining is not profitable. However, this custom hardware does not exist for Litecoin and most other altcoins (based on scrypt). Thus, you might still be able to make money GPU mining Litecoin this way.

Unless you have customised hardware, forget about Bitcoin mining.

The other contributors are correct though - doing this on a laptop is probably not a good idea anyway, but you'll still make more doing Litecoin than Bitcoin.


Which framework is best for eWallet bitcoin development?

Bitcoin wallet development usually involves communicating with either bitcoind through HTTP JSON RPC, or otherwise with other Bitcoin Clients through the Bitcoin Protocol over TCP. On top of that, there are the usual requirements of authenticating users, securing data and so forth. All of those security issues are not Bitcoin specific, thus I think this question would be better asked elsewhere.


How do I create an offline transaction in java to broadcast via blockchain.info?

Mike Hearn's WalletTool (included in the bitcoinj library) is a pretty good starting point.

If you have a look at the 'send' method in WalletTool you can see that it:

1) Creates a SendRequest

2) Decrypts the private key if necessary

3) Completes the tx to get the inputs and find the fee

4) Signs the tx

5) Starts up a PeerGroup

6) Broadcasts it

For an offline transaction you can do 1 to 4, serialize the tx and then call the blockchain pushtx.

There is a method on Transaction called bitcoinSerialize to convert it to the bytes that need transmitting. I think you just have to convert the bytes to hex for the blockchain pushtx but you would have to try it out.


Is the current network difficulty algorithm appropriate for "Peak transaction-only mining"?

Interesting thought.

Years from now we may get to a point where transaction fees are the majority of mining income and profits are so marginalized that electricity expense is a major factor. What makes sense for a miner may be to have a low-power computer with ASICs sitting idle and waiting until there are some transactions with big juicy fees, then actually start mining. Once someone mined a block with those transactions the fees are no longer up for grabs, so your equipment goes dormant again to conserve electricity.

So far not a big issue I think, because the busy and slow periods are hard to predict. The problem is if we have certain times of day when a large portion of bitcoin users are asleep, resulting in very little value available from transaction fees. Or if you could artificially create a slow period by somehow hindering the propagation of transactions.

If you know beforehand that 50% of the hashpower will switch off for a certain time period then you don't need the infamous 51% hashpower majority to pull off a double-spend - the equivalent would now be 26% of global hashpower.

So yes, if a large portion of the hashpower switches off systematically at the same time, I think that could become a weakness. But I don't see it happening until we get to a point where most, if not all, of the income from mining comes from transaction fees.


How to process refunds and ensure that after a crash you don't resend to someone?

You can check blockchain for the latest transactions of the address you are using for refunds.

Get the latest transactions of the address from the blockchain and compare those to the refunds in your system to see which ones you were able to send and which ones you weren't before the crash.


Does bitcoind generate address using the same private key from wallet.dat?

A wallet is not a single private key; it is an ever-growing collection of private keys.  Each address has a private key stored in the wallet.  Each time a new address is generated, so is a new private key.  This is even true for HD wallets, albeit the private keys are generated and stored differently.


Generally your lightning node needs to scan blocks from bitcoind or btcd. It seems like due to the fact that your node was offline lnd did not catch up processing the blocks provided by your bitcoin node. So it seems like you just have to wait until lnd catches up.


Why do people go looking for old hardware that has a wallet?

Are you talking about the people who mined or bought bitcoins in 2009 - 2011 and are surprised that the price is that high now?

HD-wallets (wallets with such a recovery phrase, it's called seed) are available since BIP 32 and that was around 2013.

So they don't have such a wallet and can't recover anything. That's why they search their old hardware.


How to send bitcoin from an offline Bitcoin Core that doesn't have a synced balance?

The easiest way to do this by importing the address you generated on the offline Bitcoin Core client into an online fully synced Bitcoin-Core. The command is: bitcoin-cli importaddress <address>. The benefit of importing this address into the synced Bitcoin-Core machine is that you can use it as a watch-only address which will allow you to see all the UTXOs related to it. You can then use the command bitcoin-cli listunspent to show you all the UTXOs and then you can use the ones related to the address in question.

Note: Below txids and amounts are made up.
Now, using the UTXOs that were shown in the listunspent output you can create a transaction on the online client using the createrawtransaction command. I deliberately used two UTXOs to show how this can be done for multiple UTXOs and also to show how other commands will look like if one of the outpoints in the inputs belong to a legacy address and the other outpoint belongs to a P2SH-P2WPKH address.

bitcoin-cli createrawtransaction '[{"txid":"27893ad827ddd94c442c561b1d3bf3d0f60571d6518e4941698e5778b25e1991","vout":0},{"txid":"776be22ff789a86283b247f99f7b2c6f7f53185cb765570bc65c6e6bb7ed8558","vout":1}]' '{"12WJykFa1hqJUJ65QbFB8dS5XNJaR22w2S":0.1}'

This would give you the below hexstring that you can copy over to your offline machine.

output: 020000000291195eb278578e6941498e51d67105f6d0f33b1d1b562c444cd9dd27d83a89270000000000ffffffff5885edb76b6e5cc60b5765b75c18537f6f2c7b9ff947b28362a889f72fe26b770100000000ffffffff0180969800000000001976a9141083323e89f0f734c448cd16d5a5513afb841b1788ac00000000

Copy over that output on the offline machine in order to sign the transaction. Now signrawtransaction command was deprecated in v0.17 and removed since v0.18. In place of that we now have signrawtransactionwithwallet and signrawtransactionwithkey. You will use the former when you want to sign the transaction from a key belonging to your wallet in Bitcoin Core and use the latter when you want to sign a transaction with a key not in your wallet by passing the private key along with the command.

Since your address was generated from a key in the wallet, we will use the first command. After copying over the output of the createrawtransaction command we had got on the online client, we also need to provide the sciptPubKey and redeemScript. This is done so that the offline client knows what the locking script is for the outpoints and which key it needs to use as it does not have access to the transactions (since it is offline).

Now, use the command:

bitcoin-cli signrawtransactionwithwallet "020000000291195eb278578e6941498e51d67105f6d0f33b1d1b562c444cd9dd27d83a89270000000000ffffffff5885edb76b6e5cc60b5765b75c18537f6f2c7b9ff947b28362a889f72fe26b770100000000ffffffff0180969800000000001976a9141083323e89f0f734c448cd16d5a5513afb841b1788ac00000000"
'[{"txid":"27893ad827ddd94c442c561b1d3bf3d0f60571d6518e4941698e5778b25e1991","vout":0,"scriptPubKey":"76a914623ff66fb88ff802fe1b8eaff666ba52307eecb088ac","amount":0.09},
{"txid":"776be22ff789a86283b247f99f7b2c6f7f53185cb765570bc65c6e6bb7ed8558","vout":1, "scriptPubKey":"a914de7dad83bb2d6e9638d347dcb3c53fe238773c9387","redeemScript":"0014df7bcc159ade813e6bd6290d97ed0bc8987dc084", "amount":0.011}]'
"ALL"

This would give you a signed transaction as an output. Let's call it hexoutput. A couple of things to note. If you pay close attention you will see that the second outpoint used in the input contains redeemScript. This is because it belonged to a P2SH-P2WPKH transaction and hence you need to provide the redeemScript next to the scriptPubKey field. For more info you can refer the documentation here.

Now copy this hexoutput over to your online Bitcoin-core client and use the below command to relay it over the network.

bitcoin-cli sendrawtransaction hexoutput

This will give you a txid of the transaction as an output that you can use to monitor your transaction.


I'm not sure what exactly you are trying to do with:

peer.on('connected', function(){  console.log('connected'); });

You can just do on ready instead.

peer.on('ready', function(){  console.log('connected'); });

Example connecting to a peer and receiving notifications

var bitcore = require('bitcore-lib');
var Peer = require('bitcore-p2p').Peer;

var peer = new Peer({host: "101.201.31.79"});
//IP of one of the btc.com's miners

peer.on('ready', function(){
    console.log("Connected "+peer.version, peer.subversion, peer.bestHeight);
});
peer.on('disconnect', function(){
    console.log("disconnected");
});
//loop through peer notifications
peer.on('inv', function(message){
    var nodeMsg = message.inventory;
    var nodeMsgLen = nodeMsg.length;
    for (var i = 0; i < nodeMsgLen; i++){
        console.log(nodeMsg[i].hash);
    };
});
//connect
peer.connect();


How would you store a bitcoin wallet for a small bitcoin exchange?

The safe way for an exchange to function is the hot-cold wallet system. A hot wallet, which the server has access to and where all deposits and withdraws get handled from.

Function of the hot wallet

The hot wallet is what your exchange will you to receive and send bitcoins with. If you are sending bitcoins to a user for a withdraw, it comes from the hot wallet on server. If you are receiving, make sure the address in in the hot wallet. A good hot wallet only keeps a small portion of bitcoins available. An amount that allows your service to run for a week or even a day without running out. Say your hot wallet was 5%-10% of your total funds, you'd daily or weekly add bitcoins or take bitcoins. If there are no bitcoins on the hot wallet, your service should come to a grinding halt. You cannot automate the filling of the hot wallet from the cold wallet, this is dangerous and is exploitable.

The benefit of this smaller balance on the server is that you cannot get robbed of all your funds suddenly

The cold wallet

The cold wallet should not be in any way connected to your exchange. It'd be best if only you had access to it. 90% of your funds should be kept here. The idea is that the attacker cannot access 90% of your funds electronically or automatically. You should manually be moving coins from the cold wallet to the hot wallet by yourself.

Note: Do not take my advice here as full advice, you should look up proper wallet management, it is a broad topic. See the Bitcoin wiki article on Securing your wallet.


Yes it could be, that your Transaction is not confirmed.
Pls check unconfirmed Transactions here:

https://blockchain.info/de/unconfirmed-transactions

~ 16000 unconfirmed Transactions.

Until they are packed in Blocks it could take some hours - days.
Depends on how large the transactions are it could take some days, because Blocks have a maximum size of 1 KB.

Sometimes there are just ~700 transactions mined per Block and it reaches 1 KB, sometimes there are > 2500 Transactions put in one block.

I think push will not be a solution because it was already broadcasted to Network.

So be patient it will be confirmed soon :)

Regards


Bitcoin to Bitcoin Cash Options

Option 1)
Seems a bit more confusing but a splitting tool available: https://github.com/NicolasDorier/BCCSpliter

Option 2)
The wallet.dat is what holds our wallet private keys. DO NOT EVER DELETE wallet.dat

Here is where you can get the Bitcoin Cash bitcoind, bitcoin-cli, etc: https://download.bitcoinabc.org/0.14.6/

[Windows] Make sure you backup your bitcoin core windows wallet if you have one. Or send the bitcoin to an exchange. This will overwrite your bitcoin core on windows.

Always backup the wallet.dat

Steps (Windows):
- Download https://download.bitcoinabc.org/0.14.6/win/
- Sync with network
- Find path (mine was C:\Program Files\Bitcoin)
- Put wallet.dat in AppData folder

[Linux] Setup a separate Amazon AWS for bitcoin cash.. This is for safety because I read that Bitcoin and Bitcoin Cash can conflict if not done correctly.

Steps (Linux):

Setup AWS Instance
- Sudo su
- passwd root
- Yum install wget
- Cd ~
- Wget https://download.bitcoinabc.org/0.14.6/linux/bitcoin-0.14.6-x86_64-linux-gnu.tar.gz
- Tar xzf bitcoin-0.14.6-x86_64-linux-gnu.tar.gz
- sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.6/bin/*
- Bitcoind
- Let sync then upload the wallet.dat


how difficult is it to generating an ECDSA (or Schnorr) signature with a certain number of leading zeros?

Not if you just do leading zeroes or just lowest value when interpreting as a very large integer.

To make things easier, let's just assume that you use compact signatures which are just the signature's R and s values concatenated with each other instead of other signature formats which have additional surrounding formatting bytes that would interfere with a direct comparison.

The compact signature format just concatenates the R and the s values. However this would be a trivially broken PoW scheme as soon as one person found a valid PoW, and that person would always be the winner. This is because the R value is just the X coordinate of a nonce which is multiplied by the curve's generator point. If someone finds a R value that works with the PoW, they can just keep reusing that nonce and always have the same valid R value. So this is obviously broken.

But if you were smarter about what is compared for the PoW by instead checking that the s value is lower than the target. The s value is computed using a formula which includes the nonce, the message hash, and the private key. In Schnorr, there are also multiple hashes and EC Curve point multiplications, which help to make it more random. So s should be pseudorandom.

But there are some other issues with a signature based PoW, although these are more directed at ECDSA specifically rather than signatures in general.

The public key to verify against must be known, and must be known to be "correct". This means that you can't just have each person participating in the PoW provide their own public key, it needs to be some fixed public key, and everyone has to know the private key.

This is because, given an ECDSA signature and a message, you can compute a public key that would validate that signature and message combo. This is why it is important that the public key is known before validating the signature. Note that this is not possible for the proposed Schnorr signature scheme as it is not possible to do public key recovery with it.

The message that is verified must be published and hash. That's pretty obvious as it's a crucial part of any PoW algorithm. But specifically with ECDSA, given a signature and a public key, you can compute a message hash that would would result in a valid signature. This is why it is important that the message is something that is hashed and not just the value that gets put into the signature algorithm. This shouldn't be possible with the Schnor signatures.

So you could use signatures as a PoW so long as you are checking s and not R for the actual PoW check. And I would suggest that you use Schnorr signatures rather than ECDSA.


This is perfectly normal and a sign that the decentralized value system is working just fine. The valuation is different across exchanges because the value of Bitcoin on exactly one exchange is determined by the active trading on said exchange.

It just depends on supply/demand on each exchange. It is recommended to have a multi-exchange approach with an offline wallet holding the majority of your funds.


How is a "standard" Bitcoin transaction defined?

This is easier said than done, IMO. There are plenty of little fact sheet web pages (e.g. https://www.cryptocompare.com/coins/guides/what-are-the-bitcoin-transaction-types/) lying around that give a list of the "Standard" Bitcoin Transaction types, but nothing super authoritative.

However, I think the most authoritative source as of this very moment is the Bitcoin core source code.

I did my own search, recently, to prep for Andreas Antonopoulos' meetup tomorrow:

https://duckduckgo.com/?q=how+can+I+find+out+if+a+bitcoin+transaction+type+is+considered+standard%3F&t=ha&ia=web

The Mastering Bitcoin book refers to it in three different chapters:

https://github.com/bitcoinbook/bitcoinbook/search?utf8=%E2%9C%93&q=%22standard+transactions%22&type=

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc#multi-signature

I also found a good link to a comprehensive list of them here:

https://books.google.com/books?id=YHfCBwAAQBAJ&pg=PA92&lpg=PA92&dq=how+can+I+find+out+if+a+bitcoin+transaction+type+is+considered+standard?&source=bl&ots=GK4gh-mjoL&sig=BHl4csT7dQZUPwT61W6-QT1qrR0&hl=en&sa=X&ved=0ahUKEwjD5JCD-obTAhUJ0mMKHdyeCBQQ6AEIQDAF#v=onepage&q=how%20can%20I%20find%20out%20if%20a%20bitcoin%20transaction%20type%20is%20considered%20standard%3F&f=false

And the 5 types, pubkey, pubkey_hash, multisig, script_hash, op_return, have some neato stats here: https://webbtc.com/stats

Long story short, I think you're just going to have to byte the bullet and get a friend who knows C++ to explain the contents of the policy.cpp file to you:

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L44

That friend will be me, shortly...

(some time later)

It looks like there are two functions that tell whether a transaction is 'Standard' by Bitcoin Core's logic: IsStandard() and IsStandardTx().

Header: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L75

Source code:

IsStandard(): https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L34

IsStandard() first checks the transaction against the Solver.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L37
Next, IsStandard() checks whether the transaction is an N of 3 multisig:
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L40
Lastly, if witness transactions are enabled, IsStandard() checks that the transaction is one of the two standard types of witness transactions.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L53

IsStandardTx(): https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L59

A standard transaction must have a sufficiently low application version. https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L61
The transaction has to have a sufficiently low weight.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L66
If a given Bitcoin Transaction is a Pay to Script Hash transaction, it must have a small scriptSig value. According to the arithmetic in the comments, that works out to about 15 M of N signers (that is, 15 "co-signers" for a transaction) maximum. AND it has to be push-only. Not sure what "push-only" means, but apparently it's important.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L76
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L89
Next, it seems that it's checking the scriptPubKey against the IsStandard() function.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L97
Null transactions are considered standard, as are transactions that have only one OP_RETURN output. But not empty multisig or dust transactions.
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L103
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L114

I'd guess this is a pretty reasonable standard to which to hold "Standard" transactions.

The comments explain some of it.

If you want to have a look at what inputs and witnesses are considered standard, you can just have a look further down the page, or ask another question on this site.


Peercoin proof-of-stake: When a person with large computing power and a person with a large stake both compete to generate a new block who wins?

In case of fork, according to whitepaper, the chain with highest consumed coin age wins:

  The protocol for determining which competing block chain wins as main
  chain has been  switched over to use consumed coin age. Here every
  transaction in a block contributes its consumed coin age to the score
  of the block. The block chain with highest total consumed coin age is
  chosen as main chain.

In actual implementation, sightly more complicated algorithm based on PoS difficulty is used:

PoS_block_trust = 2^256 / (target+1)
PoW_block_trust = 1

And the chain with highest total "trust" is preferred.

So, the answer to your question is: PoS block wins.


Qualities of "Pay to Nested Witness Key Hash"

Nested P2WPHK is just the normal P2WPKH embedded within a P2SH, to make it compatible with older wallets which don't recognize native witness addresses (bech32). Check out this for more info: https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address


How to check a bitcoin account from a dead person

How can we check this still exist/that this is real?

You have to find some more information, the name of a Bitcoin exchange, some email messages from a Bitcoin exchange, some written notes.

A Bitcoin address usually looks like these examples

1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2.
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq

A Bitcoin transaction ID might look like

f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

You don't need to keep a Bitcoin address secret. You don't need to keep a transaction-id secret. However it is vital that you keep any passwords, seed-phrases or recovery-phrases secret from everyone including helpers.

If you have some Bitcoin-addresses or Bitcoin transaction-IDs,  you can check if there is still unspent money by typing those addresses or transaction-IDs into a public blockchain explorer

  Does he have a customernumber

He might have had a customer number if he gave his Bitcoins to some business to look after for him. You would have to find some of his email or written notes that give the exact name of the business he used. There are thousands of them.

If he kept his Bitcoin in his own private wallet, he wouldn't have a customer number. He would more likely have one or more of

a wallet program on a PC or Mac
a Wallet app on a smartphone.
a hardware wallet (looks a bit like a USB memory stick)
a paper wallet (random looking numbers and letters)

He might have written down a wallet-recovery phrase - a set of 12, 18 or 24 dictionary words that can be used to recreate a Bitcoin wallet.

Don't give his passwords or recovery phrase to any helper. Don't type them into any website. Any helper should simply tell you how to use those but should not observe or participate in using those. Don't give anyone else access to your father in law's computers, phones, email accounts etc. You are likely to be contacted by a great number of very honest seeming tricksters who will steal from you and demand unlocking fees / release fees and any other kind of fee they can think of.


How to get balance from a specific address in bitcoinj?

I found the solution for this question. I used this class:

/**
 * This class implements a {@link org.bitcoinj.wallet.CoinSelector} which attempts to select all outputs
 * from a designated address. Outputs are selected in order of highest priority.  Note that this means we may
 * end up "spending" more priority than would be required to get the transaction we are creating confirmed.
 */

public class AddressBalance implements CoinSelector {

    private Address addressToQuery;

    public AddressBalance(Address addressToQuery) {
        this.addressToQuery = addressToQuery;
    }

    @Override
    public CoinSelection select(Coin biTarget, List<TransactionOutput> candidates) {
        long target = biTarget.longValue();
        HashSet<TransactionOutput> selected = new HashSet<TransactionOutput>();
        // Sort the inputs by age*value so we get the highest "coindays" spent.
        // TODO: Consider changing the wallets internal format to track just outputs and keep them ordered.
        ArrayList<TransactionOutput> sortedOutputs = new ArrayList<TransactionOutput>(candidates);
        // When calculating the wallet balance, we may be asked to select all possible coins, if so, avoid sorting
        // them in order to improve performance.
        if (!biTarget.equals(NetworkParameters.MAX_MONEY)) {
            sortOutputs(sortedOutputs);
        }
        // Now iterate over the sorted outputs until we have got as close to the target as possible or a little
        // bit over (excessive value will be change).
        long totalOutputValue = 0;
        for (TransactionOutput output : sortedOutputs) {
            if (totalOutputValue >= target) break;
            // Only pick chain-included transactions, or transactions that are ours and pending.
            if (!shouldSelect(output)) continue;
            selected.add(output);
            totalOutputValue += output.getValue().longValue();
         }
        // Total may be lower than target here, if the given candidates were insufficient to create to requested
        // transaction.
        return new CoinSelection(Coin.valueOf(totalOutputValue), selected);
    }

    static void sortOutputs(ArrayList<TransactionOutput> outputs) {
        Collections.sort(outputs, new Comparator<TransactionOutput>() {
            public int compare(TransactionOutput a, TransactionOutput b) {
                int depth1 = 0;
                int depth2 = 0;
                TransactionConfidence conf1 = a.getParentTransaction().getConfidence();
                TransactionConfidence conf2 = b.getParentTransaction().getConfidence();
                if (conf1.getConfidenceType() == TransactionConfidence.ConfidenceType.BUILDING)
                    depth1 = conf1.getDepthInBlocks();
                if (conf2.getConfidenceType() == TransactionConfidence.ConfidenceType.BUILDING)
                    depth2 = conf2.getDepthInBlocks();
                Coin aValue = a.getValue();
                Coin bValue = b.getValue();
                BigInteger aCoinDepth = BigInteger.valueOf(aValue.value).multiply(BigInteger.valueOf(depth1));
                BigInteger bCoinDepth = BigInteger.valueOf(bValue.value).multiply(BigInteger.valueOf(depth2));
                int c1 = bCoinDepth.compareTo(aCoinDepth);
                if (c1 != 0) return c1;
                // The "coin*days" destroyed are equal, sort by value alone to get the lowest transaction size.
                int c2 = bValue.compareTo(aValue);
                if (c2 != 0) return c2;
                // They are entirely equivalent (possibly pending) so sort by hash to ensure a total ordering.
                BigInteger aHash = a.getParentTransaction().getHash().toBigInteger();
                BigInteger bHash = b.getParentTransaction().getHash().toBigInteger();
                return aHash.compareTo(bHash);
            }
        });
    }

    /** Sub-classes can override this to just customize whether transactions are usable, but keep age sorting. */
    protected boolean shouldSelect(TransactionOutput output) {
        Address outputToAddress = output.getScriptPubKey().getToAddress(addressToQuery.getParameters());
        try {
            // Check if output address matches addressToQuery and check if it can be spent.
            if(outputToAddress.equals(addressToQuery)) {
                if(output.isAvailableForSpending()) {
                    return isSelectable(output.getParentTransaction());
                }
            }
         } catch (Exception e) {
            e.printStackTrace();
         }

         return false;
    }

    public static boolean isSelectable(Transaction tx) {
        // Only pick chain-included transactions, or transactions that are ours and pending.
        TransactionConfidence confidence = tx.getConfidence();
        TransactionConfidence.ConfidenceType type = confidence.getConfidenceType();
        return type.equals(TransactionConfidence.ConfidenceType.BUILDING) || type.equals(TransactionConfidence.ConfidenceType.PENDING) && confidence.getSource().equals(TransactionConfidence.Source.SELF) && confidence.numBroadcastPeers() > 1;
    }
}

EDIT: Use Wallet.getBalance(CoinSelector). Example:

Coin addressBalance = wallet.getBalance(new AddressBalance(myBtcAddress));


Understanding what is being run through Sha256

When that "hex" check box is ticked, it tells the website to interpret the hex string that you entered as representing hexadecimal bytes, i.e. binary data. Normally when you just hash that hex string, it is interpreted as a string, i.e. a sequence of characters. But you really want to hash the binary data that that string represents, and that is what that hex checkbox lets you do.


The leeway exists mostly because timekeeping is not very synchronized, overall. Computers can easily be off by several minutes, and around daylight time changes it's not uncommon to see computers off by an hour or so.

Having stuff like NTP makes things more in-sync, but one cannot expect all participants in the network to be using services like NTP.

Counting up from the Unix epoch is very accurate, yes. The ability of various computers to maintain that accuracy is not.


What happens if I send a Bitcoin to an address no one owns?

If the address is valid, the transaction will succeed. If nobody knows the private key for that address, the money is lost forever. For all practical purposes, it's impossible to guess the key for an address that you made up.


What is the easiest way to check what was the balance of address X at block Y? (without 3rd party services)

As you have rightly mentioned getreceivedbyaddress does not return a value for non node addresses, i.e. the addresses which are not in your nodes wallet.

txindex=1 in the configuration file followed by restarting bitcoind with -reindex parameter creates indexes for all the txs so that you can open them up with getrawtransaction and check the details inside the transaction.

The only way you can check for the addresses balance at any given block is to crawl all the blocks before the block under consideration and check each transaction's vout whether it contains the address under consideration. Also you will have to check whether any of the vouts you just went through have not been spent which would decrease the balance accordingly.


Even if transaction fee is set to BTC 0.00001, transactions remain unconfirmed

CoinWallet began a different kind of stress test within the past several days.  After concerns about the method in which it conducts stress tests being a violation of laws in the UK, it decided to stress test the system by giving away 200 BTC for free to the public in a manner which will have the same effect without being a criminal act.

CoinWallet is giving away private keys that have (cumulatively) up to 200 BTC in them.  The BTC community is raising to load the wallets and send the transactions to their own private addresses so that they can get to the free money.  The result of this competitive fight for the 200 BTC is that the memory pools of full nodes are being filled with double spends and transactions that will never be verified.  Eventually, the double spends will be dropped as one of the spends makes it into a block and the remaining spends become invalid, but until then, all the nodes and all the miners are overwhelmed with a lot of extra data, which places small transactions especially those with low or no fees at the back of the priority list.

The good news is that the priority function increases the priority of all transactions as a function of time, so that even no-fee transactions will eventually have a high enough priority to be forced into the next block.  However, there is no way to predict how long that will be.

You will get your test transactions back.  They will confirm eventually.  During this stress test however, it may take as much as several days if you are unlucky.

After all the BTC that have been given away have been fully processed and all the double spends have been cleared from the mem pool, you should see normal confirmation times return to the network.

Example: Five private keys made available
Article: An article describing CoinWallet's plan
Public Release: Coinbase addresses the Backlog for its concerned customers (Graph included of Mem Pool)


Is there a limit in bits for the data hashed in hash-locked script?

The maximum number of bytes pushable to the stack is set to 520 bytes, so that would be the maximum plain-text data of a secret (if you want to be able to redeem the output afterwards).

Another question discussing about this limit can be found here.


Determining sender/receiver address in transaction

There is no 1-to-1 mapping between senders and recipients. That's why things like CoinJoin is possible. Transactions are split in two parts: inputs (that redeem previously unspent outputs) and outputs (that send the coins). The redeemed coins are essentially pooled together before being sent so at this point there is no notion of which coin is which.

The transaction fee are also paid by this pool so no one specifically paid for the transaction but the sum of the inputs.


This is probably because you entered a wrong password. There was an old version of Electrum that sometimes returned a zero length seed instead of raising an Incorrect Password error.

Before posting issues, upgrade your software.


Can an account prefix in a NXT clone blockchain be longer than three characters?

No, currently the account prefix (ACCOUNT_PREFIX constant) must be exactly 3 characters. This could be fixed in future.


Choosing a blockchain fork in Bitcoin Core

From what you linked it seems to me that preciousblock doesn't supersede a longer chain, it just prioritizes one block over another at the same height.

You could call bitcoin-cli invalidateblock <blockhash> on the first block of the chain that you wish not to follow.


Cannot connect to php-mpos with CgMiner: Pool 0 slow/down or URL or credentials invalid

Oops, It turns out I didn't use stratum mining server properly, instead I used stratum alone.  There's an important distinction between the two.


How do I export my private key on MultiBit

MultiBit does not have the same dump private key options as the normal bitcoin qt. Your best bet if you want to move coins is to load your wallet of choice onto the new device, then send to that address from your MultiBit wallet. Multibit stores private keys as described here
https://multibit.org/en/help/v0.5/help_walletBackups.html
https://multibit.org/en/help/v0.5/help_fileDescriptions.html


Where can I find On Balance Volume for bitcoin? (or ETH, LTC?)

No GDAX don't offer OBV.

However, you can use www.tradingview.com and apply OBV on chart from for example Coinbase/GDAX or other exchanges.

The sign-up is free, you only have to pay if you want to use more advanced technical analysis methods.

How it looks like:


Clarifying descendants/ancestors in error cases for too-long-mempool-chain

The ancestors of a mempool transaction T are unconfirmed transactions that this transaction T depends on in order to be included in the block chain (i.e. that are referenced by its inputs).
The descendants of a mempool transaction T are (necessarily unconfirmed) transactions that depend on this transaction T in order to be included in the block chain (i.e. that spend one or more of its outputs).
In both cases there can be multiple "generations" of descendants/ancestors (e.g. descendants of descendants):
         Tb
        /
Ta  ---
        \        Td
          Tc ---/
                 \--- Te
                  \___ Tf

(Here, Ta and Tc are ancestors of Te but Tb and Tf are not ancestors of Te. Td is a descendant of Tc but Tb is not.)
As you may picture from the above outstanding piece of art, their management can quickly start to be tedious hence resource intensive.
This resource usage (mostly RAM for storage and CPU to handle chain reorganization) impacts every single node not running with -blocksonly on the network, it is thus a DOS vector that must be limited. But how?
I can point you to the bitcoin-core dev wiki which reports the word of Suhas Daftuar -one of the main architects of the system that is currently in place- regarding the trade-offs of different approaches to usage limitation, but as a TL;DR:
The mempool needs to be in phase with miner incentives (don't drop the highest-paying transactions), while limiting its footprint on network nodes. Therefore, two limits are in place for the two "views" relative to a transaction:

The size limit, accounted for in virtual bytes, of both its descendants and ancestors.
The count limit, accounted for in number of transactions, of both its descendants and ancestors.


Impossible unless you have the private key belonging to the adress.

Your friend didn't import a few "wallets", he imported a few adresses, which makes his wallet a "Watch-Only wallet" (for the adresses that were imported.)

  Is there any way i can retrieve them via finding the private keys for them to make the btc coins spendable again?

Again, if you only have a public key, master public key, or adress format, the answer is no.

If you have a seed / private key from which the (imported) address xpub/public key was originally derived from, then yes, you could recover his funds.

Edit: I feel like we're missing a whole lot of context here: Did your friend buy these "wallets"? If so- he most likely got scammed.


How can I get the transaction indexes involving a particular address

Bitcoin Core has no option to maintain an index of addresses, thus you cannot search by address or search for things related to an address.


The difficulty is not really 1.

testnet has a "20-minute rule": if no block is successfully mined within 20 minutes, the difficulty drops to 1 until a block is mined.  Then it reverts to its previous value.  However, it appears that getdifficulty returns 1 whenever the most recent block was difficulty 1, even if it was accepted under the 20-minute rule; this doesn't necessarily match the "real" difficulty.

I've asked a new question about how to find the real difficulty.  But by browsing blocks on http://blockexplorer.com/testnet, the most recent block which was less than 20 minutes newer than its predecessor is 153337, which has a difficulty of 11512.  So most likely the real difficulty right now is 11512, unless it has adjusted very recently.

Thus there are two possible ways for you to mine a block:

Find a block at difficulty 11512.  If your computation was right, this will happen on average once every 2 years with your current machine.
Wait until it has been 20 minutes since the last block, and find a block at difficulty 1 before anyone else does.  Looking at recent timestamps, it appears that difficulty 1 blocks are typically submitted about 20 minutes and 4 seconds after the previous block.  Thus, you have about a 4 second window to find a difficulty 1 block (probably even less due to propagation delays).  Based on your computation, your probability of successfully doing this on any given block is at most about 0.0007, suggesting that you would succeed roughly once every 3 weeks on average (this is probably very optimistic as noted).  Even if you do mine a block within this time, another miner may find a block at roughly the same time; if the next miner to find a block decides to accept his instead of yours, yours will be orphaned and excluded from the chain.

So it is not surprising that you have not successfully generated a block.


How to add a second user with SSH access to my Ubuntu PC running Bitcoin Core?

You don't need to grant someone access to the entire machine to be able to use bitcoin-cli. You can provision credentials using the rpcauth parameter in bitcoin.conf (it may be defined multiple times for multiple username/password combinations), and whitelist their IP address for the port you are running the bitcoin RPC on.

They can then use a local bitcoin-cli binary along with the -rpcport and -rpcconnect options to use a remote bitcoind instance.

Naturally, you should avoid leaving unlocked wallets on this server, as anyone with RPC access may spend your coins. It should be treated as a read only instance.


Why Entropie is divided by 32 (Seed to MNEMONICS)

BIP39 uses a dictionary of 2048 words. Each word is indexable with 11 bits (2^11).

The combined entropy and checksum is represented as a sequence of words from the dictionary, and therefore must have a length which is evenly divisible by 11.

If you take any integer N where N mod 32 = 0, then (N + N/32) mod 11 = 0.

So ENT/32 simply provides the number of bits which must be used for the checksum.


What does "Green address verification" mean in the context of transaction validation?

It is a way to validate a transaction without the need to wait for the blockchain confirmation, basically peoples will declare that they trust an adress and so people trusting them can directly transact with this new adress.

More infos and similar question here: https://bitcoin.stackexchange.com/a/1731/95422


Does sending coins to someone incur fees?

Yes it incurs fees but it is as low as 0.001 so it doesn't really bother. Moreover you can set what fees you want to pay from the QT if you are running QT on windows you can set it by navigating to Settings >> Options >> Main and then fill the box which says "Pay transaction fee"

if you are running headles QT on linux then run bitcoind settxfee

The time taken by a transaction depends whether you are paying fees or not if you are not paying fees your transaction will take more time than usual


Is there any "permissionless" blockchain "without a native coin"?

Ripple is actually a permissioned "chain", even if we stretch what the definition of a chain is. It is run by validators and as far as I know, it is not permissionless (which I equate with "trustless").

I do not see a specific need for a permissionless network to have its own coin or token. It could in theory still be driven on top of an already-existing coin from another network. It depends alot on your proof-of-what algorithm. You could have a network that awards "miners" ETH for doing "work" even if your own network does not have its own native token, per se.


How does a full-node index watch-only addresses?

Where are watch-only addresses stored and how does my node keep index of their balances / utxos?

Usually the software creates a wallet file just like any other and stores information in that, except the wallet file will be missing private key information.

If I want to backup and boot a new instance of my node will it retain the indexes associated with my watched addresses?

Yes

Is there a limit to how many addresses I can watch, will many make querying inefficient?

Depends on your computer and the software used. There is no hard limit but the more there are the slower it'll be.


Can I program OP_CHECKLOCKTIMEVERIFY to trigger based on external verifiable events?

Maybe not with OP_CHECKLOCKTIMEVERIFY, as it is not possible to consume an external input with that particular operation. But you can write a third-party oracle that will release some secret (i.e. a hash) based on the set of potential use-cases you have suggested, so the beneficiary could redeem the funds promised on the fulfillments of the condition.

A contract similar to that of a Hashed-Timelock Contract (HTLC) should be useful in this situation.


How can I stop Electrum re-using change addresses?

Electrum waits for confirmations to create new addresses, so if you make new transactions before the previous ones are confirmed, you'll end up reusing the existing change addresses.


How does crypto exchange got supply of bitcoins?

You have to think about it simply, its exchange service lets consider that they're exchanging potatoes for tomato instead of Bitcoin for money.

you've bought 50 kilos of potatoes from a farmer, a customer gave you 2 kilos of tomato for 1 kilo of potatoes and go on, the farmer here is mining pools which is the main source of bitcoins.

So I would say Mining pools and Bitcoin sellers, but there's no specific answer to that question so I've marked it as Primary opinion based.


Wallet.dat Bitcoin core Privatekey Recovery

Is there any method from which we can manually calculate wallet privatekey ...

You can't calculate the private-key.
You can extract the key if the wallet is unprotected or if the wallet is protected and you know the wallet passphrase (also known as the wallet "password").
You can do this using  walletpassphrase and dumpprivkey in either Bitcoin-core's debug console or using its API.
You can also do this using the equivalent methods in other tools such as pywallet.

... from a protected bitcoin core wallet.dat file?

Only if you know the passphrase for the protected wallet. Bitcoin core uses the password to encrypt the private key.
If you don't know the passphrase, you can't extract the private key.

Related:

How can I export the private key for an address from the satoshi client?
How do I export my private keys from my Bitcoin-Qt client?
How can I export all my private keys using bitcoind?


Sending Bitcoin between paper wallet and hardware wallet offline

I'd like to transfer just the amount of my purchase from the paper wallet to a hardware wallet while off line and then connect the hardware wallet to the internet to complete a purchase. I'm thinking this would be the way to keep my money safe from hackers. Am I able to do this?

Not quite, but you're close! I'll explain a couple things about paper wallets, that should make it more clear to you:

A paper wallet is a private key that is stored physically, instead of digitally. So in order to perform functions such as signing a transaction to move the bitcoins, you will need to input that private key into some wallet software that is capable of this.

With most hardware wallets, this means you'll have to input the private key into the wallet software running on a computer that the hardware wallet is plugged into.

Important to understand is that there are two ways of importing a paper wallet: just importing the key, and sweeping the key. Importing the key means your wallet will make a copy of it, so now the key exists in your software wallet, as well as the physical paper wallet. Sweeping the key means the wallet software will import the key, and then immediately initiate a transaction to move the entire balance of the paper wallet to a new address that only the hardware wallet controls.

In almost every situation, you should sweep the key. This is because it isn't possible to "transfer just the amount of my purchase from the paper wallet to a hardware wallet". When any bitcoin transaction is initiated, the ENTIRE balance of an address is moved. The amount being transacted is sent to the recipient, and whatever extra was in the paper wallet will be moved to a new 'change address' that your wallet software automatically creates and controls. For more info on this, look up 'bitcoin change address'.

So if you import your key into wallet software, spend half the bitcoin, and then check your paper wallet balance, it will be zero. The other half of your btc will be found in an address that your wallet software controls, so if you'd like to keep those coins in cold storage, you'll need to send them to a NEW paper wallet.


Power off Antminer D3 (without ssh access)

Default password admin for user root worked.


Where do I get my username and password for solo mining?

You just make them up. They just need to match on both ends (the bitcoin program and the mining program).


os.getpid() in Bitcoin's python test scripts - What does it actually do?

os.getpid() in Python is getting the current process id. The processor id is 'random-ish', in that running the entire test several times will result in a different pid, but within the same test the pid will remain constant.

The % operator is the modulus operator, which is essentially chopping off all but the last 3 digits of the processor id.

Together os.getpid() % 999 is getting a constant offset and ignoring all but the last 3 digits. This new 3 digit number of added to the constant 11000 to return the port number to use.


Typically the receiver will create a different address for every payment he expects.

That way, once the expected amount of coins have arrived at the expected address, the receiver knows which payment was fullfilled.

This is a better approach than trying to figure out who paid - something that's not generally possible and hurts Bitcoin's privacy. Typically you don't care who pays a bill, only which bill was paid.


disregard power costs for mining in the winter?

This would be approximately true, if:

Your regular heating system is a resistive electrical heater.  (Not gas or oil, not a heat pump.)
Your mining rig produces no more heat than is needed to heat your house at any given time.  (This may be false for people with lots of hardware, or living in warm climates.  Note also that your heating needs may be much less some times of day; for instance, you probably turn down your heat when you're away from home or asleep.)
Your heating system is controlled by a thermostat in your own living space (some people in multi-unit buildings have a single thermostat for the building, or some open-loop system)
You normally pay for the electricity used by your heating system (rather than having it included in rent, for instance) and at the same price as domestic electricity use
The heat from your mining rig is circulated through your house just as efficiently as your heating system does it.

I suspect that users for whom all of these are true are in the minority.  But in general, it is true that the electricity cost can be offset to some extent by reduced heating costs; to what extent depends on each individual's situation, so it's not clear how a general-purpose calculator should account for it.  Therefore, they don't.

Note that by the same token, running your mining rig in the summer may incur additional cooling costs.  Mining calculators typically don't consider that, either.


Transfer BTC from paper wallet without 3rd party (like blockchain.com etc)

Electrum does not share your private key with its server. I would use Electrum as it's very convenient, well-maintained and it does not have large storage requirements.

Create new wallet
File > Sweep private key

Some other options are:

Bitcoin Core, which expects you to download the whole blockchain. Use the importprivkey command.
BRD wallet, which is my favorite mobile wallet that can sweep from QR.
CoPay mobile wallet also has the same feature.

Electrum and Bitcoin Core are the two most popular desktop wallets. (Core was actually designed as a full node, therefore it's not very user-friendly and not the best wallet). I'm not aware of a third desktop wallet.


How much are accepted shares on GUIMiner worth?

I have just started Bitcoin mining and am using GUI Miner. I have an AMD 7870 OC edition that is mining for me.

Welcome to mining. It's a blast.

  Currently i'm getting 380 mhash/s, is this good?

For Bitcoin, it's unlikely to be profitable unless your electricity cost is very low. See How much Bitcoin will I mine right now with hardware X? for more information.

  Also how many of the accepted shares are worth 1BTC?

None. It is unlikely that you will see 1 BTC total mining on that card during its lifetime. See the above link for why.


When using the lightning network, do you have to lock or deposit your coins somewhere?

Do you lock your bitcoins on the lightning network so you can get "pegged" equivalent bitcoin tokens in the lightning network?

Yes your Bitcoin is locked into a payment channel, but you do not get "pegged" equivalent Bitcoin tokens. You are still using Bitcoin and making Bitcoin transactions, not something else.

  If these coins are locked and you sent half your coins to another user, now that person has a claim of 50% of your coins from your "locked" coins. So doesn't this mean its the same as depositing your coins into a 3rd party (lightning network) and letting that party deal with the transactions?

No. That other person cannot take your coins without you agreeing to it or doing something stupid (like broadcasting an old commitment transaction). If that person refuses to sign transactions to allow you to close the channel, you can close it yourself without risking any of your coins. You will just need to wait for the timeout to expire before you are allowed to move your coins.


Bitcoin Core 0.13 -- jsonrpc interface -- conflicted transactions

If you call listtransaction, you should get a JSON array called walletconflicts.

If your transaction conflicts with another transaction in your mempool or with a transaction in a block, this walletconflicts array is filled with n transactions-id's that points to the tx that spends the same, conflicting inputs.

walletconflicts is also present in gettransaction


Best practices for service/merchant handling bitcoins

This is probably best conveyed using the wiki:

http://en.bitcoin.it/wiki/Securing_online_services


Blockchain.info is implementing bip32 and bip39, to understand how they're work you should read more about them.

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

Simple Explanation:

When you create a wallet they create a mnemonic phrase (Bip39) and then they create your bitcoin seed using that mnemonic phrase.

that seed has a private key (xprv,zprv) and public key (xpub,zpub) for each derivation path, changing the path giving you more keys that belong to the same mnemonic phrase.

for example "MainAccount" in here has the following path:

m/44'/0'/0'/

When you create another "account" in your blockchain.info wallet they increase the last 0 to get new keys for the same mnemonic phrase.

Now we can derive addresses using public key (xpub,zpub) or private key (xprv,zprv).

which receiving addresses belong to MainAccount?

Every address has been derived from your "MainAccount" keys is belongs to that account.

total balance of MainAccount (in this case 0.7btc)?

They check each address balance belongs to MainAccount to get total balance.


Can a malicious Internet Service provider launch a double spend attack?

Everything sent over the Bitcoin network is public so you have nothing to worry if your ISP monitors your connection (only related to bitcoin transactions; your privacy is compromised in other cases). The only thing which is private are your keys, but that is not sent over the network. Now, if your ISP controls everything that moves through its servers, it can definitely change the components of the transaction. However, when you create a transaction, you sign the entire transaction with your private key. So, if any component of the transaction is altered, that signature is rendered invalid and hence the entire transaction becomes invalid. So, no even if your ISP controls your entire network, it cannot alter your transaction without invalidating it. Just ensure that you keep your keys safe (cold storage like hardware wallets or paper wallet).


What stopping miner from altering value in transaction to increase transaction fee?

The signature signs the spending transaction(*). Modifying it in any way will invalidate the signatures in it.

(*) Not actually, as it's obviously impossible for the signature to sign itself. There are also means for a signature to indicate it explicitly does not sign certain parts of the transaction, permitting those to be modified after the fact.


Trying to run the Main file of the wallet template from bitcoinj but JavaFX not found

Install the JavaFX SDK

Check this

https://docs.oracle.com/javafx/2/installation/jfxpub-installation.htm


How to move blockchain.info api created wallet to be used by bitcoin core

You would need to extract the private key from blockchain.info, and get it imported into bitcoin core. See here:

I don't know how to export a private key from blockchain.info

You may need to repeat this step, if you have several wallets in blockchain.info.
Once done, it is like having two wallets, with the same privkey. Nothing prevents you from using both.


Is the hdSeedid in Bitcoin Core 0.17 RPC the actual seed itself?

The hdseedid is the same as the hdmasterkeyid (the latter is retained for legacy reasons, it was renamed to hdseedid for better clarity). It is the HASH160 of the HD seed.

If you wish the retrieve the seed, unlock your wallet and run:

dumpwallet /some/filepath/wallet.txt

In the dumped wallet, you should find an xprv key, which is your master extended key. Note that Bitcoin Core does not support BIP39, and the xprv cannot be converted to seed words.


Exit bitcoind gracefully in a bash script

Is bitcoin-cli available? If so, bitcoin-cli stop instead of pkill $BITCOIND_PID.

My own preference is to add sleep 2 following a stop, as I've experienced issues immediately restarting the stopped daemon where it behaves like a child thread hasn't finished cleaning up before the parent exits. That may not be what's happening - I've not investigated that behaviour.


Would it be possible to dictate a bech32 address as a list of English words?

The NATO phonetic alphabet is designed for this purpose and is very widely recognized by a number of people in communication critical industries. The words are clearly recognizable even to the unfamiliar and is intended to not be able to be mistaken. Due to bech32 encoding there’s no need for communication of capital letters as you would need for p2pkh addresses.

bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq

becomes

  Bravo Charlie One Quebec Alpha Romeo Zero Sierra Romeo Romeo Romeo Seven X-ray Foxtrot Kilo Victor Yankee Five Lima Six Four Three Lima Yankee Delta November Whiskey Nine Romeo Echo Five Nine Golf Tango Zulu Zulu Whiskey Foxtrot Five Mike Delta Quebec


How or why "a Bitcoin address is a single-use token"?

The bitcoin addresses are permanent addresses. You can re-use the addresses if you want. But when reusing it causes privacy issue as any one will be able to find out the number of transactions or the total balance that address has. (you found out that there are 641 transactions in that address).

To avoid this, its better not to reuse address and use separate address for each transactions, so that no one will be able to see your balance in the wallet or transactions.


Is bitcoin.org or bitcoincore.org the one to trust?

It looks like https://bitcoincore.org/ is the one run by the people who run the Github bitcoin/bitcoin project (the actual core developers) since it is the one listed on their Github page: https://github.com/bitcoin/bitcoin
If you want the absolute best source for the client directly from Bitcoin Core devs then I would use that site or their Github page for downloads.
https://bitcoin.org is still, however, a reliable source for information on Bitcoin Core, and maintained by the community. However, it is owned by someone who isn't tied to the Bitcoin Core project itself (as far as I'm aware): https://github.com/cobra-bitcoin


What was the very initial value of OP_RETURN?

My understanding is that OP_RETURN was first introduced in v0.9.0

No, it was just changed to be standard in 0.9.0. If a transaction is nonstandard, miners running Bitcoin Core with default settings will not mine the transaction.

OP_RETURN has been around since the beginning, in 0.1.0. This was the fragment that implemented OP_RETURN in 0.1.0:

        case OP_RETURN:
        {
            pc = pend;
        }
        break;

Back then, OP_RETURN didn't necessarily cause a script to fail. You could also use it in the scriptSig of a transaction, meaning that you could steal anyone's Bitcoins by pushing a non-zero value and calling OP_RETURN. Ah, those were the days.


Does this explanation of the security of an electrum seed check out?

Yes it is correct. Bruteforcing n bits with 2048 rounds of hmac for each attempt is equivalent to bruteforcing n +  11 bits but only requiring one round of hmac for each attempt. They are equivalent because the rounds of work required to determine each secret (n bits vs n + 11 bits) are identical.


Number of nodes and channels in Lightning Network?

As for (1) yes you can use tools like the recksplorer as suggested by JBaczuk but you can also query the gossip store of your lightning node directly. Each node has to know the entire topology of the network for source based routing. C-Lightning provides a command line interface to retrieve this data.

However nodes can have private channels or be even private themselves. So with the Recksplorer which utilizes the Gossipstore and with the Gossip store you will only get a fraction of the Lightning Network. People Using Bitcoin Lightning Wallet or Eclaire mobile Wallet will currently not be public.

As for (2) I have created an autopilot for c-lightning with the python client library which analyzed the graph with the networkx module of python. you can check out the code at this pull request: https://github.com/ElementsProject/lightning/pull/1888 This should give you a starting point for doing more statistics about the topology.


Can you replicate a wallet somewhere else

Yes, using the same seed phrase on a different device/in different software will create another instance of the same wallet (assuming both wallets are following the same derivation path, etc).
This is a nice feature of BIP32 hierarchical deterministic wallets: you are not necessarily tied to the wallet software that you used to create the wallet in the first place. If that wallet software stops being developed for whatever reason, you can recreate your wallet using some other software/hardware.


How to generate PPCoins using Proof of Stake?

Yes
Yes, but it's not a great idea to do that. Coins need to sit in a wallet for at least 30 days before they start generating stake. I would never leave coins in an exchange\online wallet idle for 30 days.


How do you start the Ardor funding account monitor via the command line?

There is no specific command line option to start the funding monitor.
You can probably start it using a curl command after starting your node.

Q: When starting the monitor via the GUI, do you have to leave the browser open?
A: You can close your browser just keep your node running like with forging and bundling.

Q: Also how does fee-ratio work? Is there an example?
A: Fee ratio works like in any other API it is the conversion rate between child token and parent token used when the monitor submits its funding transactions.


Why is the transaction fee a multiple of the amount I want to send?

That's the recommended fee, the recommended fee is like the minimum amount to get your transaction included in a block ASAP. You should be able to set fees, but for small amounts like that a fee that large is common, remember, miners can only include so many transactions a block every 10 minutes, so they pick the transactions with the largest fee and smallest txn size.


How many proof-of-work algorithm exists for crypto currencies?

Any Strong Сryptography Hash Function can be used as PoW

So, the number of algorithms can be infinite. Counting the number of currently used hash-functions has no sense.


Wouldn't the expected return of a mining pool be no more than solo mining?

Yes, but it's a similar situation to taking out insurance - many people would rather pay a known regular amount to insure their car than take the chance that they'll have to pay a large amount occasionally. Like pool mining, insurance usually works out in favour of the other party, but it's still valuable in order to reduce your variability.

If you have enough mining hardware operating that your payments are relatively regular, then it would likely earn you more to solo mine. If you would only solve a block very occasionally, you are taking a significant risk you'll get a low reward or nothing at all.

However, you also need to run bitcoind to solo mine, whereas you don't when pool mining. The more mining hashpower you have, the more bandwidth pool mining will use, but running a node will use a roughly constant amount of bandwidth. Update: pools are now available that avoid this problem (Thanks, Dr Haribo).

Back in the days when I mined with my GPU, I would've had to upgrade my internet account if I left the client running 24/7, which would have cancelled out any benefit from solo mining.


Where have your BTC been on Aug 1? That's deciding.

If I understand it correctly, you created a new BTC-wallet and sent your BTC there. But your BCH are still on the adresses on which your BTC have been on Aug 1.

So you need to get the seed of your older wallet (where they have been on Aug 1) or (if you did not use a HD wallet that time) you need to get the private keys of the adresses of the old wallet (almost wallets allow you to export them). You can import them in Electron Cash then.


Who/What generates Bitcoin Hashes to be mined?

"Decrypting hashes" is not really a correct way to describe the calculation, and nobody "encrypts" them, which is probably why you could find no information on this notion.

The hashes that miners calculate are based on all the transactions on the network, metadata and previous block hashes.


How do I spend a non-standard P2SH transaction

First thing I noticed was the redeemScript, it's using OP_MUL which is disabled and you won't be able to use it in scripts.
But I can show it using OP_ADD.

If you want to play with bcoin and test the scripts, how they validate you can use bcoin.script:

Verify and play with scripts

const scriptSig = new Script();
scriptSig.pushInt(6);
scriptSig.pushInt(1);
scriptSig.compile();

or you can assemble it using just string

const scriptSig = Script.fromString('OP_6 OP_1');

Now pubkeyScript  (redeemScript in P2SH)

const scriptPubkey = Script.fromRaw('935787', 'hex');

Or more verbose

const scriptPubkey = Script.fromString('OP_ADD OP_7 OP_EQUAL');

You can use bcoin.stack to run these scripts

const stack = new Stack();
scriptSig.execute(stack);
scriptPubkey.execute(stack);

// Verify the script was successful in its execution:
assert(stack.length === 1);
assert(stack.getBool(-1) === true);

Redeem transaction

Back to the question:

const redeemScript = Script.fromRaw('935787', 'hex');
const address = Address.fromScripthash(redeemScript.hash160());
const sendto = Address.fromString('sendtoaddress');

// generate script with redeem
const script = new Script();
script.pushInt(6);
script.pushInt(1);
script.push(Opcode.fromPush(redeemScript.toRaw()));
script.compile();

// We received some transaction
// lets say coinbase
const cb = new MTX();

// Add a typical coinbase input
cb.addInput({
  prevout: new Outpoint(),
  script: new Script()
});

cb.addOutput({
  address: address,
  value: Amount.fromBTC('5').toValue()
});

const coin = bcoin.coin.fromTX(cb, 0, -1);

// From here we spend the transaction
const spend = new MTX();

spend.addCoin(coin);
spend.addOutput(sendto, Amount.fromBTC('4.9999').toValue());

spend.inputs[0].script = script;

assert(spend.verify());

// You can broadcast raw transaction
console.log(spend.toRaw().toString('hex'));


Bitcoin core HD wallet: how sensitive is the 'hdmasterkeyid' ?

It is not sensitive at all.

In particular, it does not allow people to derive addresses, does not allow them to recognize addresses that are yours, and cannot be used to infer anything about your private keys.


Using btc-e in the United States and depositing/withdrawing USD into btc-e?

If you're willing to buy BTC on Coinbase to xfer to BTC-e, when you want to cash out wouldn't you just trade over to BTC on BTC-e to xfer to Coinbase to sell for USD then withdrawal?


What should I choose - GPU Mining or CPU Mining?

It is likely that neither is profitable for you, because ASIC miners are alot more effective than any GPU mining, which in turn is alot faster than CPU mining. But don't take my word for it. This hardware comparison wiki is a good source to make an initial estimate. There is one entry listing the combination of an A10 and a HD7660G GPU, claiming to get 105 MHash/s just from the graphics card (and not listing any value for the CPU).

If that doesn't deter you---at 100 MHash/s you are looking at an expected average reward of less than a dollar per month, probably less than the electricity your computer needs is worth---please consider updating that wiki with the performance you are getting.


Are "coin mixers" actually a real thing? Can they be trusted?

Bitcoin privacy is a complicated and nuanced topic, to really get a good idea of what is involved, I would recommend reading this article. That said, I can still provide you with some more direct answers to your question:

people have been mentioning "coin mixers" to me, and told me to use them. However, (...) I just couldn't trust them, even for small amounts of Bitcoin.

You are smart to not trust your coins to someone else. In the early days of the network, some people ran 'mixing' services, which would accept deposits from users, and then return coins with an unrelated history back to those users. This would break the chain of ownership, but it has several obvious downsides:

You have to entirely trust the service to not steal your funds
You have to entirely trust the service to not be keeping logs of coin ownership
You have to entirely trust the service to be doing a good job of sending you coins with an unrelated history

So for most users, this is not a good solution to the problem of wanting to maintain privacy while using bitcoin.
The good news is that over time new techniques have been invented, that allow the user to obfuscate the history of their coins, without encountering the issues named above. Some examples of these techniques include what are broadly referred to as 'coinjoin' transactions, and 'payjoin' transactions.
'Coinjoin' transactions are a special transaction that take inputs from a large number of users, and then create outputs of equal value. As a user, the equal value output you receive from this transaction cannot be mapped back to your specific input, so you gain privacy in the sense that your output could now potentially have come from any one of the (many) inputs. By employing some clever cryptography and partially signed bitcoin transactions (PSBTs), you as a user never have to trust any server, or other participant of the transaction. The software will only sign your input if it can see that you are being paid one of the outputs, so there is no trust involved! Your coins always reside in addresses that you alone control the keys for. Some examples of wallets that provide this functionality include JoinMarket, and Wasabi.
'Payjoin' transactions provide privacy in a different way: they work to break some of the heuristics used by chain-spying companies, by creating transactions with inputs from both the payer and payee. For anyone that is not party to the transaction, it becomes difficult to infer which input(s)/output(s) were the actual payment. I believe BTCPayServer implements this feature, and there are likely a couple other wallets that can participate in this style of transaction as well (note: it is an interactive process, so you need both wallets to be capable, and online). As with the coinjoin transactions mentioned above, there is no trust involved in participating in a payjoin transaction.
There is also further research being done, to investigate the viability of other privacy enabling techniques. For example, this idea for a coinswap protocol was posted to the bitcoin-dev mailing list just a couple weeks ago, complete with a working implementation.
It isn't clear which techniques will be most useful in the future, but there certainly is a lot of promise for a more private bitcoin economy, if the right infrastructure is built and adopted.
And all of that said, by simply participating in a coinjoin/payjoin transaction, the user does not magically gain an impenetrable privacy shield. For example, if the user receives a coinjoin'd output, and then goes to search for that bitcoin address using a popular block explorer website, then they have just doxxed their interest in that address to the operators of that website (and their ISP, the NSA, etc). So now all of those entities can infer that that particular output is owned by someone at that particular IP address! Woops! Now some privacy has been lost, even if the on-chain history has been obfuscated. To reiterate what I first wrote: bitcoin privacy is difficult (but it is not impossible).

But that's not all! By using the lightning network, you remove the footprint of your payment on the blockchain entirely. Lightning transactions can be extremely private, they don't even need to be publicly broadcast, they can simply be communicated over private (encrypted) communication channels. Lightning is still in somewhat early stages of development and adoption, but it shows a great amount of promise, especially in terms of user privacy. (further to this, if taproot is adopted, then even the opening/closing of lightning channels will become more private, making lightning payments even more difficult to track).

So, to answer your last questions in brief:

Are these really a thing?

Yes

Or just another scam?

Some mixers are definitely scams, but the legitimate ones that use proper protocols are not.

How can I trust them?

You don't have to. With a good implementation, there is no risk of theft.

Do you all use them?

Every user must decide for themselves what level of privacy they want. Not all users have the same needs or desires. But I think it is generally a good idea to engage in privacy-preserving pratices.

Why wasn't this feature simply built into Bitcoin and automated?

In the future, it is entirely possible that wallets will employ these techniques 'under the hood', so that users gain the benefit of privacy, without even realizing what is going on in the background. I believe this is already the case with BTCPayServer, for example.
Other more advanced cryptographic techniques do exist, that can hide transaction information (such as output values, or addresses), but many of these techniques scale even more poorly than bitcoin already does, or have less battle-tested cryptographic assumptions, or require trusted setups, etc. Attempting to add such functionality to the bitcoin network would be a massive undertaking, which imposes a lot of risk on the network. For this reason, finding clever ways of crafting transactions to preserve privacy, without requiring major changes to the network's code, seems to be a more viable alternative.

I've mentioned a few software projects in this post; general disclaimer: I am not associated with any of those projects, I may or may not have used them in the past, and I will always encourage you to do your own research before running any bitcoin software.


I solved this problem using NodeJS v4. I did a clean install again and ran these commands:

NOTE: My user is 'test' so my home is located at /home/test. Replace 'test' with your current user.

Install NVM:

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh |  bash

After that, close and reopen your terminal and test whether NVM was correctly installed:

$ nvm --version

Install NodeJS v4:

$ nvm install v4

Check whether NodeJS was correctly instaled:

$ node -v

Install ZeroMQ and Tools:

$ sudo apt-get install -y libzmq3-dev build-essential

Install Bitcore. Today (December 2017), the lastest version is 4.1.1. This version uses two different versions of bitcore-lib and cause a conflict when you run bitcored. So, install bitcore v4.1.0:

$ npm install -g bitcore@4.1.0

Done!!

With these steps, I could use bitcore however they doesn't solve my original problem which is, install bitcore using NodeJS v8.9.3.


why did blockchain .info recovery not recover all transactions?

Maybe you used an imported address or an old address thus it can't be found by the wallet software. Only the addresses generated using the new format (bip-39) can be discovered(are deterministic). Shortly said if you used legacy addresses the wallet won't discover them because they were not derived from  a bip-39 master/wallet key.


Find where you wallet file is located which will be different depending on which operating system your using. Then replace the new wallat.dat file with your old one. If you haven't downloaded the block chain yet, then just start up Bitcoin-qt and once it downloads your coins will be in your wallet. Otherwise you will need to re-scan the blockchain at which point your wallet will have your bitcoins in it.


it is more like 3.
The client would send the tx to a full node (let aside the complexities of SPV clients), and this full node would verify the tx by some pre defined rules. If ok, this full node transmits to other full nodes.
The transaction only gets valid, if it was mined into a block. So the server you mention can be several blocks behind, but still can transmit the tx to other nodes. A very good overview of the way this happens is here:

  http://chimera.labs.oreilly.com/books/1234000001802/ch06.html

also the chapter on transactions will help to clarify the picture.


How do I move my bitcoin from mycelium to another wallet?

there should be an export function on mycelium. select the other keys on the left pane and export them. in coinomi, import them (dont sweep, that makes a transaction).

in coinomi, the import functiln appears to be under settings -> restore wallet. make sure you dont have anything of value in coinomi before restoring this way.


Can I save mining fees when doing transitive transactions?

Probably not. Clients can set whatever rule they like for transaction fees, but they normally adhere to the Satoshi client rules described at https://en.bitcoin.it/wiki/Transaction_fees. However, note the section on transaction priority; if you have an address holding some old coins, it's quite likely a transaction out of that address will have high enough priority for you to avoid transaction fees by default.

To implement what you describe, you would need a client that does something like hold all low-fee transactions in a small pool and watches for new transactions out of their output addresses. That's certainly possible to implement, but it seems to me that it would be the sort of service you'd pay a premium for, not receive a discount on.


Do I have to make a back up copy every time I make a transaction?

You just need to backup your private key or your 12 words nothing else

The whole network keep a full backup of all your transactions

If your wallet make new bitcoin address for each transaction you need to keep a backup of your new private key as well


Is the value of "satoshi" fixed or dynamic?

The value of a Satoshi is fixed.

The key word is "currently" (smallest currently possible).

If the divisibility is ever increased, a Satoshi will still be exactly 0.00000001 BTC, even though there exists unit representing an even smaller amount.

There would need to be new names for these new denominations that are even smaller than a Satoshi, but dSatoshi (1/10th of a Satoshi), cSatoshi (1/100th of a satoshi), and mSatoshi (1/1000th of a Satoshi), would likely suffice.


How does the CPU hashing algorithm used in Yacoin differ from scrypt?

The scrypt-jane modification allows the N in scrypt(N,1,1) to change. Litecoin uses scrypt(1024,1,1). GPU miners haven't taken this into account. But now you have the opposite issue. Instead of the GPU miners getting everything, it's the datacenters who have the advantage.


How did pay-to-pubkey hash come about? What is its history?

Pay to Public Key Hash has existed for the entirety of Bitcoin's life. P2PKH addresses have existed since the earliest release of Bitcoin. Creating P2PKH addresses and sending to P2PKH addresses was possible to do with Bitcoin 0.1.0.

However these early versions of Bitcoin also supported a Pay to IP address feature where your wallet would contact the wallet at a given IP address and request a scriptPubKey to send to. The response would be a P2PK scriptPubKey and thus you would create P2PK outputs.

Blocks too were mined to P2PK outputs, and in fact, Bitcoin Core still does this. Bitcoin Core's internal miner (which is only used for regtest and testnet now), still creates P2PK outputs instead of P2PKH outputs.

Pay to IP eventually began being phased out in Bitcoin 0.3.13 when its usage was hidden behind a command line switch -allowreceivebyip in commit 172f0060 (note the author is Satoshi, however he appears to have also incorporated code from someone else). The ability to send to IP was removed in Bitcoin 0.5.0 with the last remnants of the networking code related to Pay to IP removed in Bitcoin 0.8.0.

It was known before Pay to IP's removal that it was insecure. Since the only other way to transact was via addresses, P2PKH was already widely in use with P2PK never seeming to get much use as it was only use for Pay to IP and for blocks created by the Bitcoin client.

Once external mining software came about, blocks began using P2PKH instead of P2PK because it was easier to enter an address from your wallet into an external miner than it was to get a pubkey and enter it. People were also accustomed to using addresses at that point, and addresses only work for P2PKH outputs.


How can I manually add a receiving address in MultiBit Classic Wallet - disconnected during confirmation

You may have the receiving address in one of the rolling backups.
Also, if your wallet is encrypted then when you create a new receiving address then an export of all the private keys is performed automatically (encrypted with the wallet password).

Where all the files are stored is described in:
https://multibit.org/en/help/v0.5/help_fileDescriptions.html


What is the "hierarchical" about in Hierarchical Deterministic Wallets?

Hierarchy allows interesting use-cases.

You could have a master company key m/0' and give out m/0'/0/0 to company-branch A and m/0'/0/1 to company branch B, etc.

You could then allow audits by handing out the extended public keys (xpub) of m/0'/0 to some trust organization (or just hand out m/0'/0/0 if you want someone to audit branch A only).
Private key at m/0' can reconstruct all funds from all branches.

On top of that, online-shop of branch A could use the xpub of m/0'/0/0/0 to received funds while not revealing the wallet structure of m/0'/0/0, etc.

Another interesting use-case would be to map domain-names or other string-based- identity-systems to the hierarchy. Example: Github.com could result in m/71'/105'/116'/104'/117'/98'/... (very unoptimized way for demonstration purpose).


ripple consensus - mathematical certainty for all unl graphs?

The conclusion that no consensus has been reached is a valid conclusion and can result due to poor topology or Byzantine failure. Certainty is always with respect to something that has occurred in the past. It is not possible to know with certainty the present state without observing at more points than will normally be possible.

So each server runs out ahead of what it knows for certain, applying transactions and attempting to reach consensus on them. When and if a consensus is in fact produced, the server later determines this with certainty, and thus can advance what it knows for certain.

Essentially, the consensus process produces a a stream of signed messages called "validations" from which it's possible to determine with certainty whether a consensus had actually been reached at some point in the past.

It is possible to create UNL topologies that frequently fail to reach consensus. The plan is to have Ripple servers build their UNLs using an algorithm that makes such topologies exceedingly unlikely.

Even with a perfect topology, two types of Byzantine failures are possible.

One, which is not that uncommon (one out of every 200 rounds or so), is a local failure. In order for a consensus to ever arise, someone has to declare a consensus. And for that to happen, someone must declare a consensus first. When that happens, whoever makes that declaration can't know for certain that others will declare that same consensus (or they would have already done so, and so he wouldn't be first). So it's always possible that he declares the wrong consensus.

In this case, the server that suffered the Byzantine failure quickly discovers that the other validators have built a different ledger than it did and it begins its resynchronization process. Other servers will still, from the validations, which ledger was the majority ledger.

A much less common type of failure is complete Byzantine failure. In this case, several servers declare different consensuses and there is no clear majority ledger. In this rare case, the network as a whole must reconverge before a true consensus will emerge. Ripple has an algorithm to do exactly this. Servers will see the conflicting validations and know with certainty that there was no actual consensus.


How to track multiple bitcoin addresses?

usually you can use block explorers to display amounts of your different bitcoin addresses. I tend to go to "blockchain.info". As it is cumbersome to cut and paste everytime, I created a small (Linux/MacOS/OpenBSD) shell script to do this for me (https://github.com/pebwindkraft/ccy_values). There are payed APIs and non payed APIs, the latter one having a limit on requests.


Why can't you just tell the blockchain that your bitcoin was stolen so that nobody can use it?

The short answer, is because "the blockchain" has no idea whether your bitcoin got stolen, or whether you actually intended to spend it. The blockchain sees a legitimate spend and a theft as the same thing: A transfer from one account to another.

What the setup instructions are trying to protect you from is losing the private key to your wallet. If somebody learns your wallet private key, then they can spend your money. The catch is, you don't know whether somebody else has a copy of your private key until your bitcoins are gone.


transaction "unconfirmed," no idea what the problem is, running updated bitcoin core

There is currently a backlog of about 52,000 unconfirmed Bitcoin transactions.

The transaction 0ee906dd3a240d3776d609853a7e855ed813b8a1e51328405145a8cffecbb804 will be confirmed eventually.

At the very worst, the transaction will get dropped and the coins will still be in the sending address.


Will a bitcoin miner work for other currencies?

ASICs (Application-specific integrated circuits) are especially manufactured for one specific hashing algorithm. Therefore, a Bitcoin ASIC using SHA-256 will not work for Litecoin or Dogecoin as they both use Scrypt. One example for ASICs are the Butterfly bitcoin miners.

There are altcoins that also use SHA-256, such as Freicoin, Peercoin or Namecoin. An overview can be found at altcoins.com.

CPU and GPU can be used for any Coin, but the number of hashes will be different. A card mining SHA-256 (Bitcoin) at 10GH/s will produce much fewer hashes in Scrypt (Litecoin, Dogecoin), because Scrypt is much more complex.


How to activate the mining process in the standard bitcoin client?

Warning: doing what is described below will not gain you any coins at all with exceedingly high probability, and just burn electricity (see other answer).

Bitcoin Core still has a built-in miner. It is not efficient, not optimized, does not use any special hardware (like special CPU instructions, GPUs, FPGAs, or ASICs), and is only useful for testing on test chains.

You can enable it by issuing the RPC command setgenerate true, and disable it with setgenerate false. These commands can be issued in the debug console in Bitcoin-Qt, or using an RPC client (like bitcoin-cli) to send it to a running bitcoind instance.