Given a list of buy/sell orders and previous trades, compute a buy/sell price

I had been thinking about this lately and haven't explored this option at ALL but I'm thinking out loud here because nobody has replied in 8 days.

So what if you took the average of the top orders 1 - 5, then the average of the top orders 2 - 6, the average of 3 - 7, ect. Out of THOSE orders you then calculated the average again to arrive at your sell point? The process could be repeated as nessecary to find an average of averages that hover around the top of the buy points.

Thoughts?


What's the distinction between BIP 157 and BIP 158? Are they supported by Bitcoin Core?

This answer is a slight modification on the description used in Bitcoin Optech Newsletter #43. Full credit and thanks to Dave Harding!

BIP158 introduces Compact block filters, which are are based on an efficient method for encoding
a list of equally-sized items. In the case of the "basic" block
filters described in the BIP, this is a list of all the
spendable output scriptPubKeys in the current block plus all
the scriptPubKeys for the outputs spent by this block's inputs
(what developers call previous outputs (prevouts)).   Each of the
scriptPubKeys is hashed to give each item the same size and then
these items are sorted into a list that has duplicated elements
removed.  This list is then encoded using the Golomb-Rice Coded
Sets (GCS) algorithm also described in BIP158, losslessly
reducing the size of the list.  This specific basic filter provides
enough information for anyone who knows a Bitcoin address to find
any block containing a transaction either paying that address
(output scriptPubKey) or spending funds previously received to that
address (prevout scriptPubKey).  The search may produce false-postive
matches (so blocks which don't contain transactions for that address
will be included in the results), but will never result in false-negatives
(so blocks that do contain transactions for that address will never
be omitted from the results).

A separate BIP, BIP157, describes how these compact block
filters can be served over the network using the Bitcoin P2P
protocol.  BIP157 is designed to work with BIP158 "basic" filters
but it can also be extended to support additional filters that
encode lists of other items.  One particularly noteworthy part of
BIP157 is that it introduces the concept of filter headers where
the header for each filter commits to a hash of the previous block's
filter header plus a hash of the current filter.  This creates a
chain of filters similar to Bitcoin's chain of blocks and is
designed to make it easy to compare filters from multiple peers:
each peer can send just the filter header (32 bytes) and, if there
are any headers that don't match, the client can request earlier and
earlier headers in the chain until the divergence point is found.
Generating a filter header on demand for a particular block
would require hashing all previous filters, so servers that are provide
BIP157 filter headers will generally need to store them in advance.

At the time of writing (April 2019), Bitcoin Core can generate and store
block filters and filter headers, and users can access them using the getblockfilter
RPC. Bitcoin Core does not currently provide block filters or filters headers
over the P2P network.

Here is an example getblockfilter return object:

$ bitcoin-cli getblockfilter $( bitcoin-cli getblockhash 170 )
{
"filter": "0357e49590040c79b0",
"header": "349eaecc8bb7793c9f3c28e78df6675ef904515e9a310e4532785aeb45526090"
}

We selected block 170 because its filter is the first to contain
more than one element (it holds 3 elements) and because the latest
block as of this writing (block 572,879) has a filter that contains
8,599 elements---far too much for us to print elegantly.


The wallet itself is still downloading the block and is 3 years and 29 months behind. Does this mean I must wait until this finishes before it shows up?

Yes, in order to understand the current state of the network (which includes the transaction that you received funds in), your node will need to work through the blockchain history. Otherwise, your node will be unable to determine whether or not a transaction you receive is in fact valid.

Once synced with the network, your balance should display correctly.


Where can I find historical price of altcoins?

I run alt19, which is a free site which offers historical trade data on a large number of altcoins in CSV format. We have data at 15 minute, 1 hour, and 1 day increments.

http://alt19.com


How do I get the originating address using Blockchain.info's recieving API?

You can use blockchain.info's API to look this up, specifically you're looking for the inputs of the "input_transaction_hash" tx:

https://blockchain.info/rawtx/0a11043d6e067bad827d4c82da2c45e99323f3a0b28f843fae156bcbd7e8a1d2

Result:

{
   "ver":1,
   "inputs":[
      {
         "sequence":4294967295,
         "prev_out":{
            "spent":true,
            "tx_index":86277579,
            "type":0,
            "addr":"1JfkMijQTFsRbfDhqTU8Sacx2JVGiSs8af",
            "value":20470771,
            "n":1,
            "script":"76a914c1ce233e2d34facb69aa2b1233db07929586691388ac"
         },
         "script":"49304602210091a3b8759a99abcf4eaa1d3205f5d89e5243faa9ea166c3a9d2f34889dd5f86c02210080738b0beb1cbede15061d2ba5e37033bcc16848b06807e6c3ab2837ef281a99012102665ea1fd74fdb940be0245633ee276bb2abc4a650a16eb77601ed0c3ffd37293"
      }
   ],
   ...

Please be aware that actually using the "from" addresses (there are often multiple) for any purpose is dangerous and strongly discouraged, please see Can a bitcoin transaction be reversed from the receiving end? for more details.

If you have a need to collect a return address for some purpose, you should consider using BIPs-70/71/72 instead.


P2Pool latency, should I host in a datacenter or at home?

P2Pool works differently from most mining systems - it aims to have a completed "mini-block" about every 10 seconds, so latency of the p2pool hosting server is critical - milliseconds count.

So it absolutely must be in a decent datacentre on a high-quality (aka not-cheap oversold contended junk) network, not on your home connection if you expect ever to get any mined income.

You'll also have to admin the server/os/software, apply patches and upgrades and generally maintain things which can be a full-time job.

I'd suggest you just join an existing one - find one "close" to your location - do a traceroute to it - the less hops and different networks the better.


How to retrieve readable private key from bitcoinjs-lib

use .toString('hex') instead.

  Don't export / import individual private keys when you are using BIP32 HD keys. IT IS DANGEROUS.
  .toString('hex') and .toString('base64') are readable string representations of Buffers, but no crypto apps use them. The accepted format for individual private keys are WIF. But like I said, IF YOU ARE USING HD KEYS, ONLY STORE/EXPORT/IMPORT YOUR SEEDPHRASE OR AN XPUB.

Source: From this Github thread.


https://blockchain.info/pools gives you all the info you need, we're not as bad as in the ghash.io days (>51%). I count 17 pools with >1% hash rate, however the four biggest pools have a combined total of >50%.

Another thing to bear in mind, is that people with substantial hashing power (such as Antpool), could just be hiding their actual hashrate in other pools, we've seen  some pop up with some pretty large amounts of power in short order, and hundreds of petahashes swapping between pools.


Mining was never supposed to be profitable. And it's a derivative of bitcoin which is already risky speculation.

Don't add the extra, annoying risk-without-an-upside of wondering whether BFL will ship your machine in time to turn a profit. Even they state that there's no guarantee that their machines are profitable.

If you are sure that the price of bitcoin will go up, or even if you're not sure and you just want to take a bigger risk with more money, just buy more bitcoin.


BIP32 child derivation from another child

I was able to derive the first part from the second using the btcutil package from btcsuite:

package main

import (
    "fmt"

    "github.com/btcsuite/btcutil/hdkeychain"
)

func main() {
    xkey, _ := hdkeychain.NewKeyFromString("xprv9wB9jkQM6C257qp5MvUut24gTbevWcZ66K2EspGUiCJ8MFLAxSoL2ZwrQEahDCk2EugHxu5w6p5z6cHLdk9yE9bC5axxbaT49Ccs4UUPTzb")
    // go to child "1"
    child1, _ := xkey.Child(1)
    // go to child "2"
    child2, _ := child1.Child(2)

    pub, _ := child2.ECPubKey()

    serialized := fmt.Sprintf("%x", pub.SerializeUncompressed())
    fmt.Printf("Is Equal: %v\n", serialized == "04f9f02c77c6941f6352a2dd0a49964855ca239f008cd3be82532dacda0a3c79cd3872f468b85780e4bdcf377d8edf489598db1c2599cda0b850485fca2dbfb2cc")

}

Note the serialized uncompressed format is from the 1/2/1/2 node and the xprv is from the 1/2 node.

When you run this program, you should get "Is Equal: true".


Why does hashing public keys not actually provide any quantum resistance?

Although hashing a public key by itself does provide quantum resistance, this is really only when it is considered by itself in a vacuum. Unfortunately, public key hashes do not exist in a vacuum and there are many other things in Bitcoin that need to be considered.

Firstly, if public keys were hashed, the funds are only protected before they are spent. As soon as a P2PKH or P2WPKH output is spent, the public key is exposed. Whilst the transaction is unconfirmed, an attacker with a fast enough quantum computer could compute the private key and create a conflicting transaction which sends the funds to himself instead of the intended recipient.

Furthermore, if that attacker is a miner, they could do this with every single transaction and simply refuse to mine transactions that don't send the coins to himself.

While this is a problem, people often argue that it's better than someone just spending the Bitcoin outright because they have the public key from the blockchain. While that is true, there are an extremely large number of outputs with exposed public keys.

Over 5.5 Million Bitcoin are in outputs with exposed public keys, either because they are P2PK outputs, or because users are reusing addresses and thus public keys are exposed in other transactions. So if a quantum computer existed that could produce the private key for a public key in a reasonable amount of time, the attacker would be able to steal so much Bitcoin that they would decimate the Bitcoin economy and Bitcoin would become worthless.

So while your particular outputs may be protected by hashes, the value of those outputs would be 0 as millions of Bitcoin are stolen. All that the hashes really do is provide a false sense of security.

Then there are issues with tooling and wallet software the simply expose public keys in other ways than just in transactions and in the blockchain. No existing tools treat public keys as private information; there's no reason they should.

Many wallets send the parent extended public keys to a server so that the server can watch for transactions and send that data back to the client. Anyone who uses such a wallet, even temporarily, exposes their parent public key to a service provider. That provider could then compute the private keys to the public keys they have, derive all of the child keys, and steal all of the Bitcoin associated with anyone who has used their wallet.

Additional issues exist with complex scripts and contracts involving public keys. These scripts, such as multisigs, do not hash the public keys. Furthermore, these contracts typically exist because not all parties necessarily trust each other; one of them could be malicious. In such cases, a malicious participant in the contract would know the public keys involved (by virtue of knowing the script) and be able to steal the Bitcoin associated with those outputs. Existing public key hashes do not protect against this.

So overall, there are tons of ways that public keys are already exposed outside of transactions. These all would allow different kinds of attackers to steal millions of Bitcoin thereby causing the value of Bitcoin to go to 0, which renders any Bitcoin protected by public key hashes to be worthless anyways. Furthermore, users are probably exposing their public keys in unintended ways due to the software that they are using. So using public key hashes only serves to provide a false sense of security, while also increasing the size of transactions. In general, it is not worth the extra size.

Lastly, it is possible to do a transition to post quantum cryptography if it is found that a QC exists which can break ECDLP. If detected in time but still too late to do a proper upgrade, all use of signature algorithms relying on ECDLP (i.e. ECDSA and Schnorr) could be soft forked out thereby locking all coins. The coins could then be spent by providing a Zero Knowledge Proof of some non-exposed or quantum resistant information that indicates ownership of the private keys for the public key.

For example, users could provide a proof that they have the BIP 32 seed that was used to derive the private key for the given public key. Since it is a Zero-Knowledge Proof, the seed itself is not exposed (note that the seed is not part of a public-private keypair so there is no public component that is shared). Since most wallets use BIP 32, this should be sufficient. There may be other ways to prove ownership without risking coins that have not been thought of yet.

And of course, this all assumes that a quantum computer capable of computing the private key for a public key appears without the public being aware of the technology being close to existing. What is likely to happen is that the progression of quantum computers will be observed, and, at some point prior to them being powerful enough to break ECDLP, Bitcoin will soft fork in a Quantum resistant signature algorithm. Eventually, signatures relying on ECDLP will be removed. And all of that will occur before quantum computers truly becomes a thread. So in that scenario, hashing public keys provides no help anyways.

Note that all of the above is not just limited to quantum computers. It generally applies to any cryptographic break of ECDSA (or Schnorr).


Recovering an old Multibit wallet file (76 characters long)

Does anyone know the correct method of decrypting this?

It doesn't seem to be encrypted. The comments at the start of the file don't mention any form of encryption. It only mentions a common form of encoding - Base58. Encoding is not encryption so no decryption is needed.

#   The Base58 encoded private keys are the same format as
#   produced by the Satoshi client/ sipa dumpprivkey utility.

That Base58 key ought to be able to be imported into several different modern wallet programs.
See

Private keys importing in format got by dumpprivkey
How to get the private key in hex from the output of dumpprivkey
https://btcinformation.org/en/developer-reference#dumpprivkey


A bitcoin is not a piece of data, and therefore does not have a length.  A bitcoin, the unit of currency, is just like any other unit of measurement.  It wouldn't make sense to ask "how much data is a meter?", and likewise it doesn't make sense to ask how long a bitcoin is.

That said, the amount of bitcoin that is stored by an individual is the sum of all the bitcoin denoted in the unspent transaction outputs (UTXOs) that are controlled by the individual.  These are pieces of data and do have a size...albeit a variable one.  These outputs do not need to be stored by the owner, as they are stored on the blockchain.  All the owner needs to store is private keys that allow them to spend the UTXOs, which is what a wallet manages for you.

I hope that helps.


Is there a widely used symbol for satoshi yet?

No.

Satoshi is often abbreviated to sat or s, although no currency symbol
has been widely adopted.

https://en.bitcoin.it/wiki/Satoshi_(unit)


How do I see the IP address of a bitcoin transaction?

No, IP addresses are not stored in the blockchain.

But Gavin Andreson indeed notes that

  Unless you are very careful in the way you use Bitcoin (and you have
  the technical know-how to use it with other anonymizing technologies
  like Tor or i2p), you should assume that a persistent, motivated
  attacker will be able to associate your IP address with your bitcoin
  transactions.

One way to do this is to simply run bitcoin peer-to-peer clients that connect to a large fraction of the active nodes.  It's not as hard as you might think.  See Dan Kaminsky's Black Hat 2011 talk, starting at slide 21, for more.  (Thanks to kirian for reminding me of the link).  Then see An Analysis of Anonymity in the Bitcoin System 2011-07-22 by Fergal Reid, Martin Harrigan for how to link together the various bitcoin addresses that each user uses.

Some related background is outlined by Craig Reading:
Bitcoin Theft – The Top Ten Threats | Genesys Guru Blog


What does the value of bitcoins depend on?

The value is unstable because it's a small and speculative market.

People don't really understand what bitcoin is and they can be lead to believe many things.


Which is the official site to download the NXT (nxtcoin) wallet app?

There is no the official site.

You can download NRS (Nxt Reference Software) by following links from https://nxtforum.org/nrs-releases/. If you trust Jean-Luc then just check the file checksum. If you don't then analyze the source code and compile it yourself.


How would one go about generating a BIP-38 encrypted vanity address for cold storage?

Take a look at http://bippy.org.

The main potential issue I see with using a vanity address for cold storage is in spending from the address multiple times. If the wallet software you use isn't properly crafted (i.e., by using RFC 6979) there's a possibility that it will use the same k value during ECDSA on the transaction, which will make it possible to recover your private key (see this). Note that this potential issue applies to any address for which there is more than one spend, not just vanity addresses. But I bring it up in particular here since the nature of a vanity address implies a reasonable likelihood of multiple spends from the address.


How explicitly can the blockchain be pruned?

The blockchain itself cannot be pruned.

Each block is verified through hashing all its data and a random nonce to find a hash that has a certain number of leading zeroes. If you even removed a single little bit of data from a block, the resulting hash would be changed. As most likely the new hash would not fulfill the difficulty requirement, the proof of work would have been destroyed. You'd have to create a new block to take its place. Then however, you would also have to recreate all subsequent block, as the parent's hash (think of it as a fingerprint) is included in its children block, i.e. if you change the parent, the whole blockchain succeeding from it becomes invalid as well.

What can happen is that the database of verified transactions that Bitcoin-Qt clients store is pruned. So far, after verifying each block, full clients keep every transaction that has ever happened locally. Instead, you could only keep the transactions in your database of which the outputs have not been spent yet.


Each column is as follows:
  The number of devices and processors currently mining
  Hottest temperature reported by any processor
  5 second exponentially decaying average hash rate
  An all time average hash rate
  An all time average hash rate based on actual nonces found, adjusted for pool
      reject and stale rate
  The number of Accepted shares
  The number of Rejected shares and stale shares discarded (never submitted),
      and the percentage these are of total found.
  The number of HardWare errors, and percentage invalid of nonces returned


Extra Charge for Recurring Transactions on Coinbase

Coinbase is no longer paying the Bitcoin transaction fees for their customers; they are now shifting that responsibility onto their customers. This extra charge that you are seeing is likely because of this change.


Of course it isn't synced if you haven't mined blocks in a while. The assumption with networks similar to Bitcoin (and thus Dash) is that mining is constant so if a node sees that its most recent block is old, it will assume that it is not synced.

The RPC calls will check to see if you are synced and then only serve data to mining software if it is. You can just disable this check in the source code so that you can mine again.


How to close stale lightning channels with c-lightning

The problem seems that the other nodes are also offline which is why you can't connect to them.

Luckily you don't have to be connected  as you can do a force close by publishing your channel state to the Bitcoin network (the disadvantage is that you have to wait for the timelock until you can spend your outputs)

Just try lightning-cli close ENTER-CHANNEL-ID-HERE in case you are not connected your node should perform a force close


Yes, they can do that.
Correct, though the switchover requires a 95% threshold to make the chance that old nodes see confirmations on such blocks very small.
Segwit nodes never accept blocks that have a witness commitment but no witness section. Either the block must not have a commitment (in which case it will be invalid, as script validation fails), or it is outright not accepted (because there is missing data; similar to a block with missing transactions isn't accepted).
Miners that don't validate a block before mining on top of it violate the security assumptions of the network. We can't prevent them from doing so (with or without segwit), but that is one of the reasons why block propagation and block validation needs to be low-latency: so that the potential advantage miners get from SPV mining is not too significant.


Multi-signature with no address reuse . How coordination is done?

Some multisig wallets use BIP 45 or otherwise do something similar if they aren't using those specific derivation paths. Such wallets will have the cosigers share their extended public keys with each other. From those xpubs, they can derive each others child keys by themselves. They then agree that all the keys derived at index 0 are for address 0, index 1 for address 1, etc.
They may then also use BIP 67 to determine the order of the keys. BIP 67 just sorts the keys so they are in lexicographic order.
Alternative to BIP 67 is to just have the pubkeys in a predetermined order. I.e. the key derived from person 1's xpub is 1st. The key from person 2 is 2nd. And so on.
This way the participants have determined which keys to use for a particular index, and the order to put the keys. They can now construct the redeemScript and thus the multisig address. All of this can occur without communicating again.


If cryptocurrencies have no intrinsic value, how do they originate?

You seem to have a misunderstanding:

  anyone could create an infinite quantity of their own cryptocurrency right now

This is not accurate.  The breakthrough that enabled Bitcoin (and other cryptocurrencies) was the ability to make a digital asset scarce without trusting a central authority.

In the past, currencies (digital and otherwise) have required an issuing party, whom we all have to trust won't hyperinflate the currency by creating too much of it.  This might be a regional bank, a central bank, a government, or something of the sort.  Bitcoin changed this.  By using a few clever cryptographic tricks and some game theory, Bitcoin is able to give its users a very strong assurance that hyperinflation will not occur, without anyone trusting a central authority.  Bitcoin has decentralized digital scarcity.

What this means, is that there is a fixed supply (which nobody can reasonably increase) of a currency with a built in transaction network.  There is plenty of demand for such a system, yet limited supply...therefore, there is value.


Will coinbase.com have replay protection for receives?

It is impossible for the receiver of a transaction to prevent transaction replay of the transaction. They cannot do anything to that transaction to make it unreplayable.

However it is likely that Coinbase will credit both your Bitcoin and Segwit2x if a transaction is replayed. This is because they should be operating nodes for Bitcoin and nodes for Segwit2x which will inform their backend of the transactions occurring on each chain. Since a replayed transaction will be seen on both chains, both nodes will see it and thus their backend will credit your accounts.


Unconfirmed transaction - Non(e) standard input

Your transaction has obviously hard time getting accepted by miners, thus it is stuck in the unconfirmed transactions pool. If no miner decides to include it in a block (because it's non-standard), you'll wait forever - it won't automatically "fail".

The best thing you can do is create another transaction spending the same outputs, this time with standard inputs though (use BitcoinCore client if unsure). It will be picked up by the miners quickly.


How much will be the fee after all bitcoins are mined?

As fees for transactions are a free market and supply is limited (due to the block weight/size limit), the price will be whatever people are willing to pay. Those who pay less than the market rate will see their transactions slowed down or ignored; those who pay more will see them processed quickly.

What is not known is whether the resulting fees paid will be sufficient to keep the network secure. As security against chain rewriting is proportional to the cost spent by miners, we can expect that it is also proportional to how much miners are paid. If people are not willing to pay high fees at all, the security may collapse in a tragedy of the commons. If people do, and the value secured by the network is high, fees may grow very high as well.

What Bitcoin (the blockchain) technology offers you is an independent currency, beyond control of banks or nations, which permits you to autonomously audit the entire system. While you don't have to, it permits you to be your own bank and be entirely independent from third parties.

What it does not offer directly is a convenient payment system. Bitcoin transactions are slow, inconvenient, inefficient, and unreliable - and perhaps expensive too. They are pretty much the opposite of what a consumer would want as a payment system.

However, due to being a natively digital currency, without third parties that can deny you access to the system, the hope is that it can be used as a base layer in a financial system upon which actual payment technology can be built (sometimes called "layer two"). A very promising proposal that is being actively worked on is Lightning. Lightning offers cheap, reliable, fast payments, on top of the Bitcoin chain. However, not every Lightning payment corresponds to a transaction on-chain. Yet, its security is very similar to the blockchain itself and still does not rely on third parties.


How can i generate private key and its address of bitcoin,dogecoin,litecoin etc

Yeah, you can do that since the only difference between all bitcoin forks addresses is just the prefixes.

For example for Litecoin and bitcoin you could do something like that to generate address from XPUP on Bitcoinjs:

var bitcoin = require('bitcoinjs-lib');
import HDNode from "../../bitcoinjs-lib/src/hdnode";

const litecoin = bitcoin.networks.litecoin
const xpub = "YOUR XPUP HERE";
const node = HDNode.fromBase58(xpub, litecoin);
const address = node.derive(0).getAddress(litecoin);
// Bitcoin
const bitcoin = bitcoin.networks.bitcoin
const xpub = "YOUR XPUP HERE";
const node = HDNode.fromBase58(xpub, bitcoin);
const address = node.derive(0).getAddress(bitcoin);


Does Bitcoin Blockchain solves Byzantine General Problem?

The Proof of Work algorithms is a probabilistic solution to the Byzantine General's problem in the case where traitorous generals represent strictly less than 50% of the generals.

To simplify, the main thing a solution to this problem has to guarantee is that all honest generals (honest miners) agree on the same thing.

Let's assume there are 10 miners in the Bitcoin blockchain and a new transaction comes in. This transaction (noted tr1) is broadcasted among all miners. 10 of those miners are traitorous and they broadcast another transaction (noted tr2) where they changed the recipient in tr1.
Each miner will starts to solve a puzzle just after he received his first transaction message. Some will receive tr1 first, others will receive tr2 first.

The puzzle is difficult enough that, on average, a solution will be found every 10 minutes. After 10 minutes, miner M solves the proof of work problem. He broadcasts his solution to the 9 other miners and includes in there the transaction he received first. Upon receiving this solution, each miner adjusts his transaction to the new one received. They then all work on the next puzzle. After 1 hour, the chain has 6 blocks (6 puzzles solved). Each general can evaluate how much CPU was necessary to get solve 6 puzzles in 10 minutes. Each general knows then if the majority of the general contributed to building this chain. If the answer is yes, then they agreed on the transaction inside the initial block of this chain.

Now an interesting point: what if the transaction in the initially mined block is tr2? The solution described here doesn't prevent from agreeing on a false transaction. In the context of the Byzantine Generals problem, it is sufficient for the generals to agree on a false plan as long as they agree.


Anyone successfully mining bitcoins in Testnet3?

"Immature" blocks should be valid, but they require 100-120 confirmations before they can be spent.  On testnet this may take up to 40 hours or so.  If you have the block hash (it should be in debug.log if not elsewhere), you ought to be able to find these blocks on http://blockexplorer.com/testnet and see them linked into the block chain.

"Orphaned" blocks can happen if you find a block, but unbeknown to you, someone else has already found a block linked to the same parent.  This seems to be more common on testnet, which doesn't seem to be very efficient at propagating newly found blocks.  (I don't know why, perhaps there are a lot of experimental clients which don't relay blocks properly.)  This can especially happen due to the 20-minute rule on testnet, whereby if no block is found within 20 minutes of the last one, the difficulty temporarily drops to 1.  When this happens, typically lots of people find a block within a few seconds, and there is a race to see whose will be propagated and accepted first.  So every time this happens, there's a good chance you'll find a block at difficulty 1, but an even better chance that someone beat you to it, and your block will be orphaned.


Download Litecoin Core, install it,  and start it with the -testnet option.

I'm aware of two Litecoin testnet explorers:

http://testnet.litecointools.com/
https://chain.so/testnet/ltc


The callback lets you know the payment has been recieved. The confirmations are also included in the callback

  When a payment is received blockchain.info will notify the callback
  URL passed using the create method. The parameters will be supplied in
  a http GET request. The callback url is limited to 255 characters in
  length.

  Parameters

  value The value of the payment received in satoshi. Divide by    100000000 to get the value in BTC.
  input_address The bitcoin address that received the transaction.
  confirmations The number of confirmations of this transaction.
  {Custom Parameters} Any parameters included in the callback URL will be passed back to the callback URL in the notification.
  transaction_hash The transaction hash.
  input_transaction_hash The original paying in hash before forwarding.
  destination_address The destination bitcoin address. Check this matches your address.

  A double spend occurs when a malicious user spends the same BTC twice.
  A payment that initial appears successful could be reversed at a later
  date. This is counteracted by waiting for the transaction to be
  included in the blockchain and reaching a number of confirmations. 6
  confirmations is generally considered safe for high value
  transactions.

  Validate the transaction confirmations in the callback script by
  checking $_GET['confirmations'] parameter. It is recommended you
  acknowledge the transaction at zero confirmations but only trust the
  transaction after one confirmation. For example, if purchasing a
  product, we would show the order as successful at zero confirmations,
  but only ship the product when 6 or more confirmations are reached.
  See the PHP demo callback.php for an example.

sourced from: https://blockchain.info/api/api_receive


Can the fees in a coinbase be used to launder Bitcoins?

While nothing stops you from paying a high fee to a miner and claiming it out of band, trying to launder any significant amounts through this would likely be discovered and linked fairly quickly.

A pattern of disproportionately high fee transactions appearing in blocks that are mined by a subset of miners would be noticeable, as would linking the money - If you are laundering 10 BTC and put it through via these fees, I simply need to track the spends of the coinbase output instead of spends from the original 10 BTC utxo.

Of course, you could do this piecemeal by laundering smaller, less noticeable amounts like 0.01 BTC per tx, up to 0.2 BTC per block, but that doesn't really scale to a significant amount, especially not once you take out the miner's fee. Moreover, unless you are able to bring all miners on board, you could only do this a handful of times a day (assuming you manage to convince a single large pool), which again does not scale up to any significant amount of BTC, especially if you stick to doing small amounts.

It's likely simply not worth the effort for miners or launderers. Sending coins to a KYC free exchange, or exchanging them P2P for other coins, especially ZCash and Monero, likely has much higher throughput.


Is there a place or tool to monitor all addresses for unmoved coins?

In aggregate, this is shown in BitcoinDays Destroyed (e.g., unspent for one year or more).

This can be done with some degree of effort using the Bitcoin API.

v0.7 getrawtransaction gives you access to transactions even those not in your wallet.

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

There are other tools that you can use to build this capability as well.

libBitcoin
Armory (see Extras)
Bitcoin ABE


Get Latest blocks with bitcoind on Ubuntu

According to this GitHub discussion it turns out that the problem is caused by OpenSSL moving to 0.9.4.0 binaries should resolve your issue.

Gregory Maxwell

  The incompatibility is due to the OpenSSL update changing the
  behavior of ECDSA validation to reject any signature which is
  not encoded in a very rigid manner.  This was a result of
  OpenSSL's change for CVE-2014-8275 "Certificate fingerprints
  can be modified".

  While for most applications it is generally acceptable to eagerly
  reject some signatures, Bitcoin is a consensus system where all
  participants must generally agree on the exact validity or
  invalidity of the input data.  In a sense, consistency is more
  important than "correctness".


I'm not a gambler, but it's probably doable:

It depends what sort of payments your chosen gambling site accepts. If they accept bitcoins, then simply buy some BTC at an exchange funded using your bank account, then withdraw your new BTC from the exchange directly into your gambling account.

If you chosen gambling site doesn't accept BTC, you could always still transfer it via and exchange, although this seems a bit silly as there are probably cheaper services to send the money via.

With this method, you'll obviously incur transaction fees at the exchange, as well as deposit/withdrawal fees, and possibly currency conversion fees.

Another alternative that wouldn't use Bitcoin would be to send the money via TransferWise. TransferWise recently stopped handling Bitcoin related transactions, they also may not be happy about sending money to gambling websites, although I'm not sure.

tl;dr Yes - convert it to Bitcoin and back into fiat if that's all your gambling site accepts. Could prove costly though.


How is the blockchain used with the Brave browser?

Looking at the Payments tab under Brave's preferences helps to clarify the blockchain aspect quite a bit. Basically: Brave Payments is an attempt to replace the necessity of running advertisements for publications you visit to pay their bills and feed their staff. The BAT token, which is traded on markets and holds value, is used to make micropayments to publishers who's work you're viewing online. These numbers aren't accurate at all, but, for example: You load 50 BAT into your browser's wallet. If you spend 4 minutes reading an article from TheFutureOfNews.eth, you will transfer 0.1 BAT to that publisher. This way, incentive is created for work to be created and viewed, without the need for obtrusive advertising in between the viewer and creator.

As the BAT token and Brave browser are a web3 project, the proper place for the question would be over at https://ethereum.stackexchange.com/ .


What methods are currently used to embed additional data into the Bitcoin blockchain?

The accepted method of doing this is by putting the data in the output script along with op code OP_RETURN which tells clients to mark the transaction as invalid. This way, it doesn't use up as much resources on clients who don't care about non-transaction related data.

There are two schools of thought regarding putting arbitrary data in the blockchain. Some believe that as long as the method used to put arbitrary data in the blockchain follows all the rules of the bitcoin protocol, there is no harm done and that it actually strengthens the network by increasing usage. Others believe that it is detrimental and that these kinds of data should be kept from using up resources on a network that is designed to process transactions and not designed to store arbitrary data.

In my opinion, it all really comes down to what miners think about these kinds of use of the blockchain and from their perspective , they really don't care. To a miner, it makes no difference what the transaction is as long as it pays a transaction fee ,and they can add it to their block. So I believe that this kind of usage of the blockchain is here to stay.


My blockchain.info wallet was hacked. How can I create a double send to foil the attacker?

So some background as to what happened here. I wanted to claim my bitcoin diamond air drop. I googled and this video came up first.

The video played this weird music which I think was hypnotic in some way. It instructed me to paste my blockchain.info restore phrase into this website: mybcdwallet.org.

I foolishly followed the instructions and did not realise at the time that I had handed over the restore phrase of my wallet to a hostile hacker. The next morning I woke up to find that a transaction had been initiated to transfer my bitcoins to another address (not owned by me!).

Fortunately the bitcoin mempool is clogged up with lots of transactions and the hacker used a small mining fee. Consequently the transaction had not been confirmed even though it had been initiated 10 hours before.

So what I did was installed Electrum wallet and restored my wallet into it. Electrum correctly assumed that I still had bitcoin in the wallet. I then basically did a "double-spend" i.e. I started another transaction of my own and sent the bitcoins to a paper wallet that I had created. I made sure that I used large mining fee to ensure that my transaction got processed before the fraudulent one.

The next morning I woke up to find that my transaction had been confirmed 13 times which means that I had taken back my bitcoin!

Lesson: Be very careful with your back up phrases. Don't type the phrase into a website you don't absolutely trust!

I'm not not sure if I can say the clogged mempool is a flaw of a design feature. But in this case it did save me a lot of money...


Part of the design is that compromise of their service is a little bit pointless. They can not sign transactions spending your money to begin with, as the transactions also need a signature from your wallet too.
There’s no scenario in which the service can spend your money without your participation to some degree. In unlikely scenario the service attempts to force you to sign a transaction, you wait for the timeout and spend your money using the backup tool you linked to.
As with any wallet, if you lose both the seed phrase and the wallet on your phone your money is lost, those are the things which identify your money. To avoid this as a problem, don’t allow that to happen.


According the to the status message at the bottom of the page: https://github.com/bitcoinjs/node-bitcoin-exit

First permanent deployment is online at https://exit.trucoin.com:3125/


Can I ignore the blocks directory for time machine backups on OSX?

Yes, it is completely safe to exclude the blocks directory from your backup process.

In the event that you lose all your files and need to restore from backup, Bitcoin will download all missing blocks. This may take some time, but there is no information in that directory that is unique to you.


How do you sweep a paper wallet with Bitcoin-Qt?

Unlock your wallet
Run Import Command in Debug Window
Sweep to another key

https://en.bitcoin.it/wiki/Help:How_to_import_private_keys_in_Bitcoin_Core_0.7%2B

Tools needed: camera in your PC + qr code reader.
But of course you can find the private key value with classical mathematics ;)


Typically wallets do not support spending coins with any scriptPubKey except the ones they hand out themselves (in the sense that an address is a shorthand for a particulatlr scriptPubKey).

This is for good reasons. It's impossible for wallets to scan for all possible combinations and alterations of scripts with keys they know, so it would inherently be a subset anyway. It being a subset would just create unclear expectations, as senders may wonder what exactly is permitted. Furthermore, it is not the sender's business to decide what script the receiver should accept money at.

Compare this to a real life scenario where you're asked to pay someone by slipping an envelope under their door. Instead, you take the envelope and put it under their doormat. You wouldn't expect this to be a fulfillment of the payment either.


What is the incentive for continuing to mine bitcoin as we get very close to the 21 million cap?

When that runs out, the system can support transaction fees if needed.

Satoshi Nakamoto

The fact that the subsidy (newly minted bitcoins) decreases does not mean that the overall reward that miners receive decreases too: they also collect the fee of all transactions they verify and these tend to increase with the use of the bitcoin network.
Furthermore the value of the reward, measured in fiat terms, has compensated the decrease in bitcoins received with the increase in their price (at least so far).

Follow-up question: Couldn't this lead to a monopoly situation where
fringe miners give up entirely and only the biggest mining networks
reap the profits of continuing to mine Bitcoin?

For what we have seen so far, fringe miners are those have high electricity costs or use inefficient hardware, these factors affect more the sustainability of business than the scale of the farms.
It will be always possible run small farms or even a single miner (maybe using an old and cheap asic) if you have near zero energy costs.


Blockchain.info - Forgot My Secondary Password. How to recover it?

Blockchain.info has two separate "mnemonics", one for each password (using that term loosely, since it's not the type of permanent mnemonic every other mnemonic-capable wallet uses). I agree they don't make it at all clear that you gain a second one once you add a second password.

It sounds like you only have the main one. If you have completely forgotten the second password and have no old wallet backups from before you added it, then you are pretty much out of luck, sorry....

If you have some idea of what your password might be, please refer to this question instead.


Where did Staoshi Nakamoto state that bitcoin is gold or digital gold?

Where did Staoshi Nakamoto stated that bitcoin is gold or digital gold?

He didn't.
Not in any of his public writings.

an argument that Bitcoin is a store of value and not a meant of payment.

In his original whitepaper, Satoshi Nakamoto was very clear that they saw Bitcoin as a means of payment.

What is needed is an electronic payment system

The whitepaper does not mention the phrase "store of value". Since they were undoubtedly aware of this property of currencies, we must infer it was not of primary importance in the motivation for the design of Bitcoin.
So it would be surprising if there is any evidence available that would conclusively prove that Nakomoto completely changed their mind about this.

See also Breakdown of all Satoshi's Writings Proves Bitcoin not Built Primarily as Store of Value

Did Satoshi build Bitcoin to serve primarily as a store of value, or did he build it for making payments?
To answer this question, I went straight to the source. Thanks to the Satoshi Nakamoto Institute’s archives I was able to read every single thing Satoshi ever posted publicly. Comments from 260 forum threads, 63 emails, and his original source code.
After reviewing all of Satoshi’s writings, I can confidently state that Bitcoin was not purpose-built to first be a store of value. It was built for payments.


Zapped transaction, did rescan - bitcoin lost... :(

I don't think so. If the transaction is removed from the blockchain, it means it was never confirmed.

Thus the UTXO is still unspent, and should still be in your wallet. Are you sure your wallet is updated?

Maybe see if you can find the adresses by executing

listreceivedbyaddress 0 true

Or, if that doesn't show anything, dump all the private keys of your wallet and import them in something like electrum?


I tried to use bitcoin to buy ethereum and failed, what will happen now?

The Bitcoin won't magically revert back to your wallet. Contact the exchange and let them know, and they'll handle it, either by processing the exchange or refunding you.


Is it possible to autoforward bitcoins to another address?

Why do you need to forward the coins to a different address? You already control the private keys for the address that they were sent to, no need to move them to another address in your wallet. All you are doing is incurring additional transaction fees.

Instead of forwarding them to another address, just make sure that you have the private keys to all of the coins and spend them from those addresses as necessary.

If you are doing this for auditing purposes, then use an HD wallet and publish the master public key. This allows anyone to derive the addresses that you used (without needing the private keys or having access to them) to check the balance of your wallet. If you do that, just make sure that you do not reveal any of the child private keys as that will result in the master private key (and thus all of your child private keys) being revealed.


Why was the chain with the largest work chosen as the metric of consensus?

At the time Bitcoin was invented PoS, PoD, PoE, did not yet exist.

Having said that PoW is arguably still the most secure today. The most popular PoW alternative today. PoS will always arguably be vulnerable due to the "Nothing at Stake" problem:

https://download.wpsoftware.net/bitcoin/pos.pdf

"The point is this: even if stakeholders are bonding coins with a large market value, in a way that they will lose the coins if they behave dishonestly, this is only a deterrent to dishonest behaviour until they move their coins, which, being an event in the future (both in realtime and blocktime), is necessarily not something that can be detected at the the current point in blocktime. So cheap histories, or “costless simulation”, are not something that can be prevented while only bonding value defined inside the system"


Bitcoind Performance for production usage

address generation

Make sure your using HD here (A wallet created with bitcoin core 0.13 will be HD).

Address generation is pretty fast, make sure your using a large keypool –keypool=5000 in the conf-file maybe.
Also, you can pre-generate addresses and stored them in a cache-database.
But be aware, if an attacker manages to compromise that cache-database, he can probably redirect funds.

Address generation can also be done outside of bitcoin-core. Check BIP32 (HD Wallets) and maybe have a look at public key derivation. If you need performance, have a look at libbtc (C library with CLI, can derive addresses very fast).

  withdrawal

At this point, you very likely are stepping into the realm of "hot wallets". Make sure your building a secure environment.
This step involves ECDSA (signing of inputs) which requires the according private keys.
Signing is not very fast (depends on your requirement). But you can perfectly measure this with a regtest setup (sign 1000 transactions and measure performance).

  notifications

Don't use -walletnotify (it forks a process = very slow).
Try to use ZMQ (you might need to add some extra code for the wallet).


Are there minimum transaction fee, and is it based on the number of input transaction (UTXO)?

are there minimum transaction fees?

No, you could also pay no fee but your transaction will probably not be included in a block then. This is a pretty old example-transaction with no fee paid: https://blockchain.info/de/tx/8131ffb0a2c945ecaf9b9063e59558784f9c3a74741ce6ae2a18d0571dac15bb

  and is it based on the number of input transaction

Not on the number but on the size in Bytes.

  So is there harm for having too many small/dust UTXOs?

Yes. You can see it at the moment. People pay around 1.80$ for a "one address to one address"-transaction. More inputs/outputs means a bigger size. Bigger size means higher fees.


How do I compile Core 0.8.6 on Ubuntu (EC2)?

You can use the gitian build system. Instructions for building 0.8.x with gitian are available here: https://github.com/bitcoin/bitcoin/tree/0.8/contrib/gitian-descriptors and here: https://github.com/bitcoin/bitcoin/blob/0.8/doc/release-process.md. Using gitian should get you exactly the same binaries as those that were released.


Regarding audience: ETIs are regulated. Not just regulated, but they are marketed for sophisticated investors. In fact regulation prevents marketing these for general audience, so there shouldn't be issues having investors who do not know what they are doing. Investors in this case are banks and pension fund like actor, though I am not sure what's the definition of the sophisticated investor in EU.
Regarding cost: There is a premium cost bringing a new investment vehicle to market. Mainly, because to have something regulated it should be insured. Bitcoin is very new. Financial market operators are not familiar with all risk models yet. Thus, insurance carries a high premium. BitcoinETI is audited by PriceWaterhouseCoopers and needs to pay various fees to stock markets, exchanges and such. For comparison, Digital Currency Group's Grayscale Bitcoin trust carries 2% maintenance fee.
Regarding transparency: BitcoinETI prospectus is public, vetted by regulators and all fees are clear up front. The ETI must publish it Net Asset Value (NAV) continuously. Public blockchain doesn't include fiat nominated (USD, EUR) transactions of traded Bitcoins. These are internal to Bitcoin exchanges. Some exchanges choose to publish this data independently. Even if it's published, it is suspected that many Chinese exchanges manipulate this data. As virtual currency exchanges companies are not regulated, this practice cannot be confirmed or stopped.


Private key of a specific bitcoin address

You cannot.  If you could, the cryptography on which Bitcoin relies would be worthless.

I don't know who this "special intelligence unit" is, but if all they did was find the address, then that is no help.  (If the "intelligence unit" took money from you to find out this address, and told you that they had recovered your funds, then you've been scammed again.)

You have not recovered your funds and you are not going to.  Your time will be better spent figuring out how to do without them.  Sorry.


What are all the payment channels implementations?

The Lightning Network is much more than an implementation of a payment channel. It is a peer-to-peer network whose core purpose is to route payment through a set of multiple payment channels.
Then, i think you are confused with regard to the quote: "many others" here refers to
persons not projects. See this wiki page for mentions of some of them.
Finally, as you mention Elements is defining sidechains (a peer-to-peer network whose core purpose is to update a block chain that is somehow pegged to Bitcoin) which are not "building on the concept of payment channels".
However, payment channels may (not yet deployed) be a good abstraction for interconnecting sidechains with Bitcoin or in-between them.


What's the best way to get rid of 1 satoshi dust?

In the current environment, I doubt that you can.  Blocks are full these days, and the block space needed to spend your UTXO, whether as its own transaction or as one input of many similar transactions, could be used instead for a transaction with a much more lucrative fee than 1 satoshi.

I think your "aggregated" strategy would only work if one of the other participants was very generous and donated a sufficiently large fee to raise the average for the whole transaction to a competitive level.  You'd be getting a free ride in that case.

In theory, one could spend the dust in a transaction having only an OP_RETURN output, either of value 0 (thus leaving the 1 satoshi as a fee) or of value 1 satoshi (thus destroying the satoshi).  However, nobody is going to mine it on the BTC mainnet, as mentioned above, and for that matter nobody is going to relay it either, since it's dust.

(Incidentally, it appears that spending the UTXO in a transaction with a single P2PKH output of value 0 does not accomplish this; such an output remains spendable (!) so it doesn't reduce the number of UTXOs.  Example on the BCC testnet.  I wasn't expecting that.)


When a block is "discovered" how is the nonce determined?

Basically, there is no such thing as a "correct" nonce, only a set of possible "correct" blocks which can use any nonce they wish to obtain an acceptable hash.  So the nonce is just "some arbitrary number".  But in order to understand how nonces work, you first have to understand the hashing process by which blocks are produced.

Cryptographic hashes are a mathematical way of turning any set of data into a random number, called a hash.  The hashing process is designed so that it's easy to calculate the hash of some data but nearly impossible to find data which will fit a specific hash, having even a slightly different set of data will produce a totally different hash, and so that the only way to find a hash with a particular property (say, being below a certain number) is to calculate lots of them until you get lucky.

In the Bitcoin network, only blocks with certain hashes get accepted and included in the official list.  The criteria for which blocks "count" is that their hash has to be below a certain number called the target.  The network adjusts this number up and down according to how frequently blocks are passing the test--this is how it's able to keep the rate of block production at an average of 10 minutes per block.  So if the target is

00000692856290566183958127638592383846392938562929689273923968

then a block with a hash of

00000739485762992939239823472938472569106923385616929838472389

won't be accepted, but blocks with hashes of

00000683060299472046094517810601040976920106812102601296720934

00000000000000000000000000000000000000000000000000000000453737

or

00000692856290566183958127638592383846392938562929689273923967

will all pass with flying colours.  These aren't real hashes--they're just examples.

A miner is taking a list of checked and valid transactions, putting them together in the right format, and then calculating their cryptographic hash.  But let's say that the hash they get doesn't meet the criteria (as most of them don't).  What are they supposed to do?  The only way to get a different hash is to use at least slightly different data.  So instead of messing up their list of valid transactions or anything like that, blocks have something called a nonce in them.  The nonce is just a meaningless number that can be changed as many times as you like so that you can check a bunch of different hashes and see whether they pass the network's difficulty check.  So when a miner is checking billions of hashes per second (as many of them are) they are just changing the nonce to something else, checking the hash of the whole block; changing the nonce to something else, checking the hash of the (now slightly different) block; changing the nonce again, etc.

In this sense a "correct" nonce is simply the one that allows the block to hash to an acceptable number.  Just like there are many acceptable hashes, there are many different nonces which will work for the same block.  But a miner only has to find one of them.  Whichever one they find first is just fine.

You may also be interested in how the target is calculated.


Not sure if this is helpful, but here's what I think you should think about when you hear "Bitcoin wallet":

A Bitcoin wallet is a set of accounts that you can (a) spend coins from and (b) receive coins into.
An account is one and the same thing as a secret key and its corresponding public key [1].
To spend coins from an account, you need to perform a digital signature using that account's secret key.
Thus, anybody in possession of the account's secret key can spend all coins from that account. In other words, your secret key better stay secret and please don't lose or "forget" it. Or else [2].
To receive coins from Alice, you have to give Alice one of your accounts' public key [1].

Now, armed with this knowledge, I think you can answer your own questions:

  A Bitcoin wallet itself is nothing more than a "record" that is stored
  on Blockchain. It's an identifier that will be used in a person's
  Bitcoin transactions.

Yes and no. A wallet is a bunch of accounts. Each account has a "record" in the blockchain: there will be an entry of the form (_public key_, 10 bitcoins) for that account [3].

  A Bitcoin wallet app is simply a software tool to create transactions
  that are written on BlockChain

Yes. A wallet app is a piece of software that manages all of your accounts' secret keys and enables you to perform those digital signatures that let you spend your coins. Those signatures are over transactions of the form (_my public key_, _recipient public key_, x bitcoins) as I detailed in [3].

  I think some BitCoin wallet providers -- not sure if "provider" is the
  right term -- may keep some information about the user's
  wallet/transaction information on their own system.

I'm assuming you are talking about folks like coinbase.com, which manage your wallet for you? Recall that if they're gonna allow you to spend your bitcoins with a click of a button online, then they need your accounts' secret keys. So yes, they store that. And sometimes they're hacked and you lose your money [2]. On the other hand, if you don't use online wallets like coinbase.com, managing your own secret keys can be dangerous too: I have heard many stories of people losing their hard drives and thus their bitcoins.

  The value added by those who provide BitCoin services are simply
  providing user-friendly tools to read/write information from
  Blockchain. They may also be providing a method of converting real
  currency into cryptocurrency and vice versa e.g. trading or purchasing
  of BitCoin

The value part of this is in "opinion land", but yes, I suppose I agree: it's much more user-friendly not to mange your secret key and worry about losing it or being hacked. Still, you might just be replacing one worry with another: now coinbase.com might be hacked and your bitcoins gone [2].

And yes, some wallet providers like coinbase.com let you convert USDs into bitcoins and viceversa.

I hope this helps.

[1] Sometimes you'll hear the term address, which can be thought of as a "fingerprint" of the public key. To keep things simple, I will not distinguish between the two. Although, in practice, you will give the address, not the public key, to folks who want to send you coins. (This has to do with efficiency reasons and a bit of security.)

[2] Every time you hear about one of these "Bitcoin hacks," it's because someone's secret key got stolen => the victim's coins got sent to the attacker's account using a digital signature via the stolen secret key.

[3] To be more specific, there are actually a bunch of entries recording transfers from some other account into your account: (_public key_ of sender, your account's _public key_, 5 bitcoins sent to you)


What are the benefit of mining an empty block

Miners aren't forced to include transactions in their blocks even though they're incentivized by fee to do so.
The main cause for empty blocks is spy mining, as there's normally always something in the mempool! I don't see an answer on here containing 'spy mining' so here we go :)
Spy mining is when pools try to minimize time spent hashing an out of date block. A spy miner monitors the work other pools give out to miners (by registering a miner there)
If one of those pools starts working on new work, pointing to a block the spy miner has never seen before, he interprets it as the network has accepted that block and everyone else has moved on.
However, the spy miner hasn't received or validated this block so he doesn't know what transactions were applied, and hence is uncertain about the state of the UTXO set. If he includes a conflicting transaction in his block, his entire block will be rejected. So his safest chance of succeeding is to not add any transactions except the coinbase.
Eventually his software will receive the block, and the pool will include transactions in newly issued work.
This is slightly at odds with the timestamp on the block (30 minutes after the previous one), but it's hard to know.


It looks like in some places you're using testnet addresses (tprv.., m..) and in other places you're using mainnet addresses (xpub.., 1..). If your software is expecting one and gets the other, then you'll likely have some problems (like Electrum not letting you click 'next'). Check to make sure all the software you're using is configured to give you the desired outputs.

See: https://en.bitcoin.it/wiki/List_of_address_prefixes


How does my bitcoin node know that a node it connects to is running the same version of the protocol?

What different versions of the protocol/network? All protocol changes were backwards compatible, so there really is only one Bitcoin protocol. There are a few op_codes that old nodes don't interpret correctly, but they're fine with that.

Unless you're talking about altcoins and Bitcoin, they don't have the same seed nodes, so they wouldn't find each other. Even if they were, they'd ban each other for relaying invalid information.

This it's for example what happens if a  protocol is upgraded that is not backwards compatible. Old nodes see that information from new nodes doesn't adhere to the rules and stop talking to them.


What does "peer sent transaction already received" mean?

The "???"s mean that P2Pool has no estimate because nobody is mining on this node. "Peer sent entire transaction ..." is printed when a little bandwidth is wasted because peers are forwarding transactions needlessly.


There is no restriction due to segwit, but witnesses are serialized differently than scriptSigs.

A scriptSig is a script on itself, which gets executed, and its resulting stack is then fed to the scriptPubKey (or redeemScript in case of P2SH). This is not the case for the witness: it is an encoding of the stack directly, without script involved.

That means that scriptSig can use opcodes like OP_3 (which pushes the byte array 0x03 onto the stack). In the witness, you'd need to serialize that byte array directly as 0x0103. The 0x01 there is not an opcode; it is just the length of the stack element.


Researching Bitcoin Wallet clients to use? Which one provides the best peace of mind?

From this description, rather than choosing the best client to use, you should simply export your private keys to a wallet file. At any point in the future, you can load your wallet file into any almost any client and access your bitcoins.

Not all clients currently allow you to do this, notably the Bitcoin Wallet app on Android by Andreas Schildbach. In this case, you should send your coins to another address created with Electrum, Bitcoin-QT, Armory or Blockchain.info as all of these allow you to export your private keys. There are other apps/web apps that allow you to expot you wallet, these are just the ones that you mentioned that I know can do it.

Once you export you wallet containing your private keys, you can keep it on any device. You don't necessarily need to buy a new laptop or even a phone. A simple USB key could work and you could load the keys from it onto any computer any time you needed to spend your funds.

Alternatively, you don't even need a client application. It's possible to generate a public/private key pair outside of applications connected to the block chain. And any bitcoin sent to the public address will be available using the private key. But, I wouldn't recommend this unless you really know what you're doing. If you don't do this in a cryptographically secure manner, someone else could generate the same public/private key pair and access your bitcoin.

Update:  The Bitcoin Wallet app on Android by Andreas Schildbach does, in fact, have an export option.


From where can I import live cryptocurrency market values into my webpage?

Take a look here: https://blockchain.info/api

https://blockchain.info/ticker gives you a json-object with recent data.


Correct way to use joinpsbt for manual coinjoin?

No, that won't work. joinpsbts must be used before any signatures are created. Otherwise existing signatures will not be valid for the joined transaction. Rather, each person must create their own PSBT, send them to each other or to some coordinator where the PSBTs are then joined together with joinpsbts. Then the joined PSBT can be distributed back to everyone, who processes and signs it. Once signed, each person must, again, send the signed PSBT to everyone else or to the coordinator where all the PSBTs are combined with combinepsbt. Then the combined PSBT can be finalized and broadcast.

Note that currently joinpsbts has a major privacy leak as the inputs and outputs are added to the joined PSBT in the order that the transactions were specified. There is an open Pull Request that fixes this issue.


Short answers: yes, yes, no.

The longer answer is that you should stop thinking in terms of accounts/addresses - they are irrelevant as they don't really exist at the protocol level (they're just a client-side abstraction in the wallet).

Bitcoin functions in terms of coins, very much like your physical wallet containing coins. Coins are produced and consumed by transactions.

Every coin has a value (between 0.00000000 and 21000000.00000000 BTC), and an address of its owner (that's a simplification, but it suffices for now).

Every transaction consumes one or more coins. This is done by referencing them explicitly (by stating the hash of the transaction that created it), and providing a signature (for each) that proves you are the owner. They are consumed entirely: they're either spent or unspent, there is no "withdrawing" or "crediting" of/to them.

Every transaction also produces one or more new coins, whose sum in value cannot be more than the value of the coins consumed by the transaction.

As transactions deal with complete coins all the time, this means we sometimes have leftovers that need to be returned. This is what change addresses are for. When you have a coin of value 3.1 BTC, and you want to pay me 1 BTC, you'll create a transaction with one input (consuming the 3.1 BTC coin), and two outputs (one 1 BTC coin to me, one 2.1 BTC coin to a possibly different address of yourself).

Even though the concept of "balance of an address" is well-defined (the sum of the value of all unspent coins assigned to that address), this concept does not exist at the protocol level. You always work with full coins, and arbitrary amounts that get added/subtracted from balances (though the value of those coins is arbitrary).


Segwit Address Supporting Testnet Faucet

Ended up using Manu's faucet with a nested p2wkh address NP2WKH.

It will reject native Segwit addresses P2WKH.


How does an SPV client forms a transaction which is then Broadcasted?

Generally speaking, the SPV wallet receives the transaction and a merkle-proof from a validating full-node when funds are sent to an address controlled by the wallet.

The merkle-proof guarantees that the transaction with the output spendable by the wallet is committed to the header of its local (strong) header-chain. Since the wallet controls the private keys to this output, it indexes this as a local UTXO, without any knowledge of the full UTXO set found on the validating node.

When spending funds to another address, the local wallet will solve for an optimal set of local UTXOs for this transaction. Prevout Points, spendable by the wallet are indexed as mentioned before. All other transaction fields you describe are independent of the UTXO, or can be inferred from the indexed previous transaction (e.g. timelocks enforced by CSV/CLTV output script operations). The destination address will tell the wallet what output to spend to, as is the case with all other wallet types (P2PKH, P2WPKH,P2SH, P2WSH etc).

The SPV wallet described above necessarily reveals the addresses it is interested in to receive merkle-proofs from the validating node. There are several techniques for the SPV client to improve privacy and leak less information, at a certain bandwidth cost.

Server side filters (e.g. Bloom filter (to be deprecated))
Client side filters (e.g. Neutrino)


Why is this 12-word mnemonic deemed invalid by multiple wallets?

Blockchain.info did not use HD wallets or BIP 39 in 2013. Their change to HD wallets and BIP 39 mnemonics was fairly recent (within the past year or two IIRC). The 12 word mnemonic that you have is not a BIP 39 mnemonic. Rather it is a custom mnemonic used by blockchain.info for recovering passwords. The mnemonic itself encodes the password to your account (or information to recover the password from blockchain.info). It can only be used with blockchain.info and their legacy wallets.


Is it possible for a valid block to be added to an invalid one, and have it accepted by another client?

As every Client verifies each block they receive and reject every Block that is invalid, this situation is rather unlikely to happen. However, if by chance some invalid Block would propagate (such as in case of value overflow bug, or perhaps by being spread by some alternative Clients that don't follow the Protocol to the letter), it would eventually be wiped out of the Block history and orphan all Blocks attached to it. Alternatively, the Protocol could change to accommodate the Block, but that is a lot less likely to happen.

When part of the Block Chain would become invalid, all Transactions contained in it would be re-evaluated - coin generation Transactions would be discarded, all Transactions that spend their outputs would also be invalidated, and all other Transactions that are still valid would be added back to the pool of Transactions to be added to future Blocks. Same thing would happen in case of some Blocks being overwritten with a longer Chain of Blocks.

All in all, an invalid Block being accepted as valid and having valid Blocks appended to the Chain after it is a bug. Such cases have happened in the past at least once, and the result has been to fix the bug and erase the invalid Block along with all other Blocks attached to it. All normal Transactions from those Blocks would have to be added again to newly created Blocks and any coin generation Transactions would be invalidated.


Bitcoin client incentives to share peers and blockchain

If data is not shared, Bitcoin won't work. So the people who want Bitcoin to work and be useful share the data. If there aren't enough people who want Bitcoin to work and be useful, then it doesn't matter whether anyone can get the data or not.


Bitcoin wallet showing balance, Blockchain receiving address shows 0.00, wallet is from 2009 and hasn't been synced

If you can still log into the OLD wallet that has the BTC in it, you could try to set up a New Wallet under a different email address and then pay yourself. It will move the currency you have in that wallet to the new one.
You'll have to pay a fee though, unfortunately but if that's the only way to get it back and on a New Wallet where you can access the BTC again and have it synced up with the rest of the blockchain... that's what it may come down to.
If you're still having trouble let me know, I have an old wallet with scrap coin I'm gonna try a few things to see if it's been updated ever and see if I can send it to my new wallet.


Why countries like to create their own cryptocurrency?

I'm just thinking now the possibility of government issued crypto currency (maybe blockchain technology) and the miners are the banks only, this way government is not putting banks out of business and there can still be central bank who controls all the banks and issue order if needed more money in the economy (if Etherium based which I think the preferred type of all governments).

This can even go in parallel with government existing fiats so people can have two choices (good publicity for the government).

But the question still remains the same, if ever government wants to push on this, "how can they know who owns what?" If this can be solved I think government will definitely step into the world of crypto currencies....


"randomly selected scientists" - randomly selected by whom? And will you have scientists in every city across the world? And how will they get paid?

Ideas like that are practically impossible, and if you remember how PGP key signing parties ended up you'll understand why nobody is pursuing it.

The way Identifi is doing trust and reputation is one way to solve this. The other way is BIP75, which could be used to present a certificate signed by some certificate authority mutually accepted between you and the other parties. This article goes into some detail about that.


Bitcoin data directory files details are here: https://en.bitcoin.it/wiki/Data_directory


Clients
The word client is normally used for a client-server arrangement. One example is the world wide web where web-browsers like Chrome, Firefox and edge are clients. Web-servers like  apache-webserver and IIS are servers. Clients need servers, clients and servers do entirely different jobs.
Bitcoin doesn't really use a client-server model, it uses a peer to peer model where every node is the same. At least, that was the case in the beginning. Bitcoin was originally designed to avoid the need for trusted third parties but many commercial businesses have entered the Bitcoin world and some of them use a client-server model for the software they provide. This answer will focus instead on the peer-to-peer model used originally and still used by popular wallets like Bitcoin core.
Wallets
A wallet does several jobs:

It stores data locally.

The only truly important item is the private key (or master private key)
It also caches a local copy of the transaction journal (the blockchain)
It keeps other records of transactions etc it has been involved in.

It provides a user interface for a person to spend money, see historical expenditure etc
It creates new unconfirmed transactions that spend money controlled by it's private key

It sends these to a few nearby peers to be passed on so they eventually reach miners.
Consequently it has to initially discover some peers and keep contact with them.

It keeps track of the amount of money under it's control (often called a balance)
It communicates with a few other peers to learn about new blocks of transactions

Note that the only vital task is storing a number that is kept secret. Everything  else is comparatively unimportant.
Paper wallets
a paper wallet is a number written down on a piece of paper and kept secret.
Paper wallets obviously only do the first of the jobs listed above. Storing a private key. Money can be received by a paper wallet because the recipient of a transaction is purely passive and not really involved in the processing of any transaction. The sender only needs to know an address for the recipient, beyond that the recipient is not involved.
Paper wallets were useful for long-term storage of money. However the person who created that wallet would have to have some external means of keeping track of the amount of money. This could be other paper records, use of blockchain-explorers or some other system.
To spend money, the owner of a paper wallet would have to copy the secret number into a software or hardware wallet.

Related questions:

What kinds of wallets are there?
How transaction happen in blockchain?
I sent Bitcoin to an address but the recipient hasn't yet received it


Do dollars reach MtGox through other channels than Dwolla?

Yes, you can transfer cash to Mt.Gox using a service like BitInstant.


Why do merchants accept Bitcoin as valid currency?

I think the best reasons right now are:

Marketing: being the first to do something attract a lot of interest and media.
No chargebacks: Bitcoins does not allow any kind of chargeback, which is not true for main payment systems (Paypal, Stripe, Credit Card).
Lower fees or no fees, just depends on how you use it.
Investment some people wants to hoard some BTCs and offering their services in BTC is the easiest way to get some.


Bitcoind When sending a payment how can I know how many inputs and outputs there are?

When you use bitcoind's internal wallet and its related RPCs, it will automatically calculate the transaction fee for you and include that in the transaction. You can then retrieve the transaction fee used by using the gettransaction command. If you want the fee rate that was used, you can use the fee from gettransaction and divide that by the size returned by gettransaction.

Edit: To get the fee before you send, you can create the transaction with only the outputs you want (i.e. no inputs) with createrawtransaction. Then you can use fundrawtransaction to fill out the transaction with inputs. That will also give you the fee that the transaction is paying. Then you sign it with signrawtransaction and send it with sendrawtransaction. There is no other way as the other send* RPCs create the transaction, select coins, sign, and send all in one command.


You can use online wallet, like StrongCoin, then it doesn't matter where you access it from.
You need to use an Android client that allows for private key import/export. I'm not sure which Android client does this, but for Windows/Linux you either can look for some tools for altering the wallet.dat for the standard Client, or use an alternative client with import functionality (as far as I remember, MultiBit can do that, but I'm not 100% sure).


Most pools define their target value (minimum value required to earn a "share"), as:

T = 2 ** (256 - 32) - 1
= 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

The Bitcoin protocol defines a difficulty of 1 as a target of:

D = 0xffff * 2**208
= 0x00000000ffff0000000000000000000000000000000000000000000000000000

They are nearly equal:

T/D = 1.0000152590218967

The precise target used for earning shares could be set to a larger number, but that would increase the number of getwork requests sent to the server as shares would be easier to find.  Note that if you decrease the size of target, you would reduce the probability of finding ANY valid shares for a given block header (unless you allow changing the timestamp as well as the nonce).  As it stands, the expected number of shares found per getwork request is approximately 1 (when the target has 32 leading zero bits).


I can't seem to find it either, I'm pretty sure that they used to show it. The market depth is available in their API though and if you want something a bit more user friendly it is also available on Bitcoin Charts.


How can I verify the the PGP signature of bitaddress.org?

who has actually verified the code is not malicious in the first place?

There are many eyes on it from cryptographers, javascript programmers and more.  But there has been no commercial party or individual who claims to have vetted the page to assure that there is nothing malicious.

As far as verifying that the website is serving the same release as the version control repository shows, that can be verified as follow:

Verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description vx.x in github:

https://github.com/pointbiz/bitaddress.org

Here's an example of verifying in which the version was v2.4:

First check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
1d5951f6a04dd5a287ac925da4e626870ee58d60  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html --> 200 OK

Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.4"
eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb v2.4 French translations

$ git checkout eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb
$ git rev-list --max-count=1 HEAD
eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb

$ sha1sum bitaddress.org.html
1d5951f6a04dd5a287ac925da4e626870ee58d60  bitaddress.org.html

As long as that sh1sum matches the filename and also matches from github, then you can you know have the exact same version as was distributed from github.


how to be a maker for either bid or ask orders on bitcoin exchanges?

In general, you can't know for certain.

Let's say you want to buy.  You will be a maker if, and only if, your price is below the lowest price of any sell order (the Ask price) at the instant your order is placed on the exchange.  If your price is above the Ask, it will be instantly executed and you are a taker.  (At least, up to the extent that the open sell orders are large enough to fill it.  If the sell orders at or below your price do not fill your entire order, then the rest of the order remains on the book.  The exchange might charge you the taker fee only for the part that executes immediately, and the maker fee for the rest; you'd have to check their policies.)

You can check the order book and try to name a price above the current Ask.  But there will always be some delay between the moment you check the book and the moment your order arrives at the exchange, and it's possible that further sell orders arrive during that window of time.  So you can never be sure.

(It's possible that the exchange might have an option to only enter your order if it would be a maker, and to cancel it otherwise.  You'd have to ask if they offer such a thing.)

Note that the Last price is irrelevant to all of this.  It only gives the price of the last order that executed.  If additional unmatched sell orders have arrived since then, it's entirely possible that the Ask price is below the Last.

If you want to sell, then everything is reversed: you are a maker if, and only if, your price is above the highest price of any buy order (the Bid price).


How to get the available balance of a specific address using blockchain.info?

Your question:

  How to get the available balance of a specific address using blockchain.info

The description for the /balance API:

  List the balance summary of each address listed.

So use /balance.

/unspent lists all the outputs for all addresses you provide in one big list, not grouped by address. But since you're just adding them all anyway, it doesn't make much difference for you. The /balance result is shorter and simpler.

  basically want to know the total amount available to spend on each address(actually on the whole wallet but there is no such api call

Have you checked the Wallet API? "Fetching the wallet balance" looks like what you need.


How to differentiate between sending and receiving address in blockcypher api result?

You should look at

   "inputs": [
        {
          "prev_hash": "017ce1c080eda9c5364b6efbcbd2d9b790983bb36fb81316d53269bb83703f08",
          "output_index": 0,
          ...
          "output_value": 269570000,
          ...
          "addresses": [
            "1rundZJCMJhUiWQNFS5uT3BvisBuLxkAp"
          ],
          "script_type": "pay-to-pubkey-hash",
          ...
        },
        {
          "prev_hash": "02be075b8e6cf357fd34f81eaa273e9e4f5f970af3dc01b9fa07ae0d1795cb75",
          "output_index": 1,
          ...
          "output_value": 3876180000,
          ...
          "addresses": [
            "1rundZJCMJhUiWQNFS5uT3BvisBuLxkAp"
          ],
          "script_type": "pay-to-pubkey-hash",
          ...
        },
        ...],
        "outputs": [
        {
        "value": 47981690876,
        ...
        "spent_by": "fe6a1669bc5c00171b921d7883ff674a7ac3fb8cd6a986ef6c69175d336ffc89",
        "addresses": [
            "15Z9atbppxt97unmzBdGkHuSx9UdptwqDb"
        ],
        "script_type": "pay-to-pubkey-hash"
        }
        ]

These are the relevant lines.


You can use the btc-e exchange for example.


Which address gets the money from the multisig transactions? (and multisig in general)

I don't know how a 1 of n multisig transaction would affect the balance display of individual wallet clients, but because only one of the two addresses must sign, the coins effectively belong to both until one spends them.

To explicitly address your bullets:

A multisig output can be used for escrow, but it only affects the multisig output itself.  Because this output only needs signature of one, it doesn't make for effective escrow.  2 of 3 outputs with two parties and an arbiter make for good simple escrow.
In this case, either address can spend this output
In this case, the funds are 'freed' when either party decides to spend them.  In a 2 of 3 escrow situation, an unsigned transaction is created to spend the multisig output and then two of the addresses must sign that transaction individually before it becomes valid.  Broadcasting the fully-signed transaction frees the coins by sending them to whatever output was specified, which could very well just be a regular address.


Bitcoin: can transaction and its parent be in the same block

I.e., is it possible to add transaction and its parent to the same block?

Yes. The "parent" transaction must be earlier in block.


How does a gateway IOU differ from any other IOU on the Ripple network?

It doesn't differ.

Gateways are just issuers that you somehow have more trust for, so much trust that their IOUs can basically be treated like cash.

This is what happens in the current financial system, when you see $100 on your bank account it doesn't mean that you actually have $100. It just means that you hold your bank IOUs.

From what I understand there is no technical distinction between both types of IOUs.


How to start programming your own Bitcoin client?

I don't believe anyone has published a detailed spec anywhere if that is what you are hoping for.  There is some information on the bitcoin wiki, but your best option is to review the existing implementations.

Check out BitCoinJ (a from scratch bitcoin implementation in Java) and BitCoinSharp (a C# port of BitCoinJ).  They are not full implementations yet, but they are very far along and can do most of the tasks of a bitcoin client.

No matter what language you plan to create your implementation in, looking at these is very valuable because they are very thoroughly commented and much easier to understand than the official C++ client.


Here's a simple way to do it:

On bitaddress.org, use the "Paper Wallet" tab and create 1 address
Using your Bitcoin client, send an amount of bitcoins to the Bitcoin Address on the paper wallet
Print the paper wallet and give it to your friend
Tell your friend to create a wallet at My Wallet. He can then use the "import from paper wallet" feature and simply scan the QR code to import the bitcoins.

Please note that when handing over a private key "offline" like this both you and the receiver will have access to the funds if you keep a copy of the private key. The receiver has to trust you to not take advantage of that before he has had the chance to move the funds.

bitaddress.org by the way is a client side tool so you are not trusting them with your money, though you might want to read this: Should I trust bitaddress.org?


Comparison BTC and ETH uncomfirmed transactions queue

The ethereum chain has a far higher number of transactions than the BTC chain. This is mostly due to ethereum's faster block time, and the presence of many thousand smart contracts on ethereum, which all contribute to more transactions.

In the comments, it seems like you are comparing the transaction volume charts to the trade volume charts.

Trading of BTC and ETH happens largely on exchanges. These exchanges have trading engines that execute all trades within the exchange itself, and not on the blockchains. That is to say, if User A sells to User B, there is no corresponding blockchain transaction transferring those coins. Instead, both users have accounts on the exchange which are debited and credited. A blockchain transfer only takes place during deposits and withdrawals.

Through this process, many thousands of trades can take place without ever reflecting on the blockchain. However, interactions with smart contracts must happen on the blockchain, and contribute towards the total transaction volume.


Is there any tool to index ALL bitcoind UTXO?

This is something that bitcoind doesn't do, but there are block explorer tools that work on top of it that will give you address-specific utxos:

https://github.com/bitpay/insight
https://github.com/coinbase/toshi
https://github.com/bitcoin-abe/bitcoin-abe


How New Bitcoin Addresses not using Signature ? Only witness or Very Short Signature?

It looks like that API is just simply broken. If you look at the web page results (or a different blockchain explorer's API for that address, all of script and witness information is presented correctly.


How can I avoid the "Amount too low" message in my wallet for payout from Cloud mining service?

Use the custom miner fee setting to lower fees.  The fee categories make no sense.  If you want a payment to be received in a day or two - faster than ACH, you should set the fee to 10 satosi per byte or so.


A miner must create a block whose header, when hashed, is numerically less than or equal to the target value for the block. Each block contains a list of transactions whose merkle root is included in the block header, and the list must have at least one transaction in it, called the coinbase.

The coinbase collects all fees of other transactions in the block (the difference between the sum of outputs and the sum of inputs of each transaction is its fee), and adds a subsidy, which was initially 50 BTC, but halves every 210000 blocks.

The coinbase can have any regular outputs like any other bitcoin transaction, as long as the sum of the output amounts is less than or equal to the sum of all fees in the block plus the subsidy. Usually, the miner will put their own payout address in the block template which they attempt to perform work on.

The potential for earning partial bitcoins is a system built separately from the bitcoin protocol, in which miners pool their computing resources to collectively attempt to mine a new block. The block reward is then distributed among the members of the mining pool according to the amount of work they contribute. This distribution can be achieved directly and without the need to trust a pool operator, by having each miner's reward being paid out directly as a coinbase transaction output.


and(older(10),pk(A)) malleable if top-level, can it be top-level? EDIT: not malleable, was mistaken

OP_CHECKSEQUENCEVERIFY is a redefined OP_NOP code, so it cannot manipulate the stack - only abort or continue. In your script, that means it leaves the 10 on the stack, and no <any-nonzero> is necessary in the witness (and adding one would be a violation of the CLEANSTACK standardness rule).


Sequence of events that can cause lost money in MultiBit

When you create a new receiving address it is written to disk and backed up locally (ie on your disk).

If your disk was destroyed or stolen you would lose your bitcoin yes. This is why we recommend backups on another machine or USB drive.

There is no hidden key pool in MultiBit


what is the significance (if any) of "ACKs for top commit:" in the git commit messages of bitcoin core?

From https://github.com/bitcoin/bitcoin/blob/v0.18.1/CONTRIBUTING.md#peer-review:

  Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over GitHub, mailing list and IRC discussions). The following language is used within pull-request comments:

  ACK means "I have tested the code and I agree it should be merged";
  NACK means "I disagree this should be merged", and must be accompanied by sound technical justification (or in certain cases of copyright/patent/licensing issues, legal justification). NACKs without accompanying reasoning may be disregarded;
  utACK means "I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged";
  Concept ACK means "I agree in the general principle of this pull request";
  Nit refers to trivial, often non-blocking issues.

When a Pull Request to Bitcoin Core is merged on GitHub, maintainers use a script that automatically incorporates the ACKs provided by reviewers in the merge commit.


There's a lot going, but I'll do my best.

  QUESTION: Can the bitcoin network randomly select a subset of the existing nodes, for each block, who then compete to solve the hash?

Selecting a subset of existing nodes isn't easy as it seems. The vast majority of bitcoin nodes aren't reachable at all, in fact. That's why every website that counts those are different from each other. (The best probably being Luke Dashjr's one).

So you might: "Well, you could make it so that in order to participate you have to public announce your node". But that opens up (from the top of my head) a big attack vector: DDoS's. If every node participating in the consensus is known and reachable then you could hit them once they are selected and cause a network failure.

But that's not even the most important part: This approach would be extremely easy to gamble. Any person could run thousands or millions of nodes (Amazon Web Service has 1 million business customers) and change the odds to their favor.

Proof-of-Work is not a consensus algorithm, but rather an Anti-Sybil protocol. Sybil being the attack that I described in the last paragraph.

  Can the lottery fee approach achieve the same goal without sacrificing
  security?

Absolutely and 100% no, if you take "without sacrificing security" serious. And (1) I'm not sure if it can be done at all or (2) if it would work, but regardless: no.

  The result is a huge energy burn

This is a little off-topic but I feel that might be worth commenting. Bitcoin energy usage is far from "deadly" or something like that. Most researches point to +70% use of renewable energy in the industry, highest than any other.


What is the Big-O for LN bandwidth? Can anyone answer this or provide a link to a spec that is sufficient enough for us to calculate it?

This is an excellent question but still probably a little bit under specified. Let me try to give an answer and elaborate.

When looking at network bandwidth there are several componants playing into it.

The most obvious (and probably most dominant) one is specified in BOLT 07 routing-gossip. There are 4 messages which are used to provide the information about the gossip protocol to every node.

The announcement_signatures Message
The channel_announcement Message
The node_announcement Message
The channel_update Message

While the first one is only sent between two peers to decide if a channel stays private or not the second and third needs to be delivered to every node. The way how gossip achieves this is by forwarding the message to each peer if it was received and novel to the node. The amortized / expected network bandwidth for those messages should thus be O(E/V*(E+V)) where E/V ist the average node degree. And E the number of edges and V the number of nodes. In the worst case (unrealistic) of a fully connected graph we have E=V*V and thus O(V^3 + V^2) = O(V^3)

The situation is even worse for the 4th message. Everytime the routing fees are adjusted by a node this message needs to be delivered to every other node and creates O(E/V*(E)) messages. While the 3rd and 4th message will only be propagated when received first. The update message can be send every second and will be propagated Everytime. This the network bandwidth req can be arbitrary (? Still bound by the second) large even for small networks. This is obviously also a ddos attack vector. There is the million channel challenge by rusty to stimulate this behavior.

Other less dominant components are messages that are only exchanged between peers to maintain the channel state. While connecting, handshakes etc seem neglictable there is the case of routing. Let us in a first step assume that every routing process is successful the bandwidth will then grow as O(b*t) with t being the number of transactions or payments being done by the network and b being the betweeness centrality of the node on the fee graph which according to this video is likelihood of that node being on a cheapest path. This would have to be corrected by the likelihoid of routing failures. For the overall network it could be the product of number of transactions times average Pathlenght times average number of routing attempts.

There is also the network bandwidth coming from the Bitcoin node but that should not change with the growth of lightning.

I hope I didn't miss anything. Stuff changes drastically with AMP routing since every payment is split into several small payments.