Each node maintains a separate, individual mempool. While the default limits its size to 300 MiB, each node operator can set their own value. Note that the mempool size limit does not pertain to the serialized data or the transaction weight of the queued transactions (which is what is written to the block and what you see listed on a mempool monitors respectively), but to the actual memory usage of the deserialized transaction data on the node. This memory usage is platform dependent. In result, transactions start getting dropped when mempool monitors reach a block depth of about 80-95 blocks.
When a node's mempool limit is reached, it will drop the transactions with the lowest feerate and increase its minMempoolFeeRate. It will communicate its new minMempoolFeeRate to its peers, basically telling peers not to forward transactions below that feerate for the time being. Note that every node does this individually, so a node with a larger mempool or different architecture may drop transactions earlier or later. Nodes will keep a copy of transactions that are relevant to their own wallet. Even if all other nodes have dropped a transaction, the sender and recipients of a transaction would retain a copy. The sender can either force his node to drop the original transaction and send another conflicting transaction to update it, or their node will continue to try to broadcast the transaction so that it will eventually get relayed on the network again once the backlog has receded.
After the backlog decreases under the 300 MB limit and with some added delay, a node will lower their minMempoolFeeRate and start accepting transactions again that it previously expelled.
You can currently observe this happening e.g. on Johoe's mempool monitor¹:
As you can see, the 1-2 sat/B band dropped around 7am that morning when the node's mempool exceeded its limit.

¹Note that there are two BTC views and the linked and relevant in this case is BTC (default mempool))


how to get unspents of an address using bitcoind?

You should send your addresses as following:

bitcoin-cli listunspent 0 9999999 '["1PGFqEzfmQch1gKD3ra4k18PNj3tTUUSqg","1LtvqCaApEdUGFkpKMM4MstjcaL4dKg8SP"]'


I am unable to sync with the network because I have too little disk space

I would suggest running bitcoin core in pruned mode if you don't have enough space to for the entire blockchain.

You can start bitcoin with the -prune=X command line argument or put prune=X in your conf file, to limit the amount of space used by the blockchain to only X megabytes. It will delete the old blocks and keep only the most recent blocks on your computer.

Related answer: How to free up the space taken by bitcoind?

Alternatively, if you just want to recover your coins, you can backup your wallet file and move it to another computer that has more space for example.


How does Mastercoin avoid double-spend attacks without it's own blockchain?

The answer is double-layered:

Mastercoin uses Bitcoin for timestamping. It's impossible to revert the transaction at the Bitcoin level without doing a Bitcoin double spend (super costly).
Mastercoin clients track the state of the system including how much is stored at each address. If a client double spends by sending two contradicting Mastercoin transactions, the second one will be discarded as an invalid spend by any client that parses the transaction stream.


So... I found out what was wrong. The problem was in this part of the code when i was adding the inputs. I was adding an index to each input based on which number of input it was.

for(var a = 0; a < input_utxos.length ; a++){
    tx.addInput(input_utxos[a].tx,a)
    sum_outputs+=parseInt(input_utxos[a].amount);
}

but the index i was supossed to send was actually the index on the transaction outputs. so it had to be like this

for(var a = 0; a < input_utxos.length ; a++){
    tx.addInput(input_utxos[a].tx,input_utxos[a].n)
    sum_outputs+=parseInt(input_utxos[a].amount);
}

The index was gettable from the api that provided me all the utxos for an account. In this case, it was called n and was inside the transaction object itself.


How to find values of Prev_Hash and Tx_Root

Look at a block on a block explorer.

Here the Prev_Hash is called 'Previous Block' and the Tx_Root is called 'Merkle Root'.

For more technical info, take a look at the Protocol Documentation.


several approaches, just wondering about the public keys, that you mention... wouldn't you have "amounts", that should be multiplied by current value (in Euro or Dollars) per currency? Then this:

http://www.coindetail.com/

alternativly the el-cheapo version at the command line, which I cut&paste into an ods (xls) or similiar:

#!/bin/sh
####################################################################
### an 'el cheapo' approach to fetch data from coinmarketcap.com ###
####################################################################

log_fn=ccy_values.log

echo "`date '+%Y-%B-%d'`"                       > $log_fn
echo "`date '+%H:%M'`"                         >> $log_fn
echo "running ccy_values.sh on `hostname -s`"  >> $log_fn
echo " " >> $log_fn

today="`date '+%y%m%d%H%M'`"

wget -q -O - https://api.coinmarketcap.com/v1/ticker/bitcoin/?convert=EUR   > /Data/tmp/tmp_$today.tmp
wget -q -O - https://api.coinmarketcap.com/v1/ticker/ethereum/?convert=EUR >> /Data/tmp/tmp_$today.tmp
wget -q -O - https://api.coinmarketcap.com/v1/ticker/aeon/?convert=EUR     >> /Data/tmp/tmp_$today.tmp
wget -q -O - https://api.coinmarketcap.com/v1/ticker/siacoin/?convert=EUR  >> /Data/tmp/tmp_$today.tmp
wget -q -O - https://api.coinmarketcap.com/v1/ticker/storj/?convert=EUR    >> /Data/tmp/tmp_$today.tmp
wget -q -O - https://api.coinmarketcap.com/v1/ticker/storjcoin-x/?convert=EUR    >> /Data/tmp/tmp_$today.tmp
cat /Data/tmp/tmp_$today.tmp | grep -e "id" -e "price_btc" -e "price_eur" | sed -e 's/"//g' -e 's/,/ /g' > $log_fn

# create terminal output
tail -n 18 $log_fn | awk 'BEGIN { print "Currency (source: coinmarketcap.com)\tConversion Rate (Bitcoin)\tin EUR"} { ORS=""; print $2; if( NR % 3 == 0) print "\n"; else print "\t";}'


How do hardware wallets integrate with software clients/nodes?

Sadly there is no standard yet.

But a wallet standards group is being formed and some meetings are planed (april 2017).

At the moment, each hardware wallet provider writes plugins for wallet-apps which is a strange development direction.
There are Trezor/Digitalbitbox/Ledger plugins for Electrum and Copay,... but the plugins are in the source code bundle of the corresponding wallet-app provider, leading to the problem, that the hardware wallet provide has no direct way of fixing bugs or even improving the plugin.

A standard would be the right direction.


Bitcoin transactions are not reversable. The only way for you to get your bitcoins returned is by convincing your business partner to send them back to you.


A side chain is a blockchain that runs parallel to the main bitcoin blockchain and can synchronize with it directly, allowing decentralized value transfer between the two chains. A user is able to essentially lock up a certain amount of coin on the main bitcoin block chain which then frees up an equivalent amount of coin on the side chain. This side chain may be either a sidechain compatible altcoin or just some test ground for new Bitcoin features. The coin that was transferred to the side chain can be returned back to the main bitcoin blockchain at any time. The value transferred back will be the same as the value transferred out.


Question about nSequence with regard to bip-0112 and bip-0068

So turns out the sender has to set the same number in the nSequence that is in the script. In the case above 10 will be interpreted as 10 blocks because I was using bitcoinJS lib which converts the decimal 10 to a 32 bit integer which would be

00000000000000000000000000001010

according to bip68 https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

the last 16 bits is the value i.e. 10 in binary signed twos compliment is
0000000000001010

the first 16 bits represents the flags, so as they are all 0s it means the disable flag is set to off and the type flag is set to off which means the number is interpreted as blocks

however if I did this

00000000010000000000000000001010

it would be interpreted as time span, i.e. 10 * 512 seconds

for anybody like me who needs to stop thinking in terms of decimal/ints and start using 32 uint and thinking in bits/bitshift operations etc
there's a handy bitcoin-js lib which will convert it for you

https://github.com/bitcoinjs/bip68


A 51% attack does not allow the attacker to spend coins they do not own; the usual rules of validity still apply for transactions and blocks. If those rules are broken, the block/transaction will be ignored by the rest of the network, no matter how much hashpower the miner making invalid blocks has.

This question has a more complete explanation of what a 51% attacker can, and can not do.


What is the difference between a market and limit property in the MTGox API?

A limit order is an order to buy or sell at a specific price or better. As in "sell these coins if I can get at least X USD per bitcoin."

A market order is an order to buy or sell at the best available price. As in "sell these coins for whatever people are willing to pay right now."

Not 100% sure about this, but I believe mixed_currency means the buyer and seller are using different currencies. If you buy bitcoins using EUR from someone selling for USD then MtGox will do a conversion.

And yes, the best view of the market would be with all trades included.


In Deepbit how do you get the Bitcoins transfered to your wallet?

Yes. Otherwise, the cost to transfer the Bitcoins (when you want to spend them) will wind up equaling or exceeding their value.


How do you calculate the transaction fee when sending to multiple addresses?

I use the following formula:

148*I + 34*O + 10

where I is the number of inputs and O is the number of outputs.  The actual size will vary by I bytes since an extra byte is prefixed to an address that starts with 0x80.

The transaction fee is for each kB (1000 bytes) of the transaction, so you should be safe by using 0.0001 BTC per kB as the fee.  Note that the transaction size is rounded up to the next kB.  So a 1001-byte transaction will be charged two transaction fees.

More information here:
Protocol specification
Transactions


Please help! How do I transfer my wallet from bitcoin core to MultibitHD?

Put request in multibithd. Scan or put the address shown and put it in the btc core and make sure the receiving amount in multibithd is the same as the sending amount in btccore. No fees thats for sure


What are the most historic code changes on bitcoin core?

The oldest one is from Feb 14, 2016 but I'm sure historically significant changes to the code were done since.

Indeed, date opened is not always a good indication of controversy or significance, it could also mean a change which has received very little review due to its insignificance, or very little rebasing/nit-fixing due to lack of time by the creator. It's common for more important changes to be the focus of more urgent review allowing them to be merged sooner. Perhaps you should try sorting by number of comments or number of reactions, but even then it depends what you deem "significant".

  Does any one constantly (like everyday) review all commits outside of the bitcoin core team?

By definition, someone who is actively involved in the review of PRs would be considered part of the "team". There is really no team, just volunteers, anyone is free to come and help out on GitHub, no requirements or prerequisites. Many users help out in this way, and you could be one of them :)


Is it possible to force a person to honor a conditional promise-to-pay?

It is possible to create a small transaction output as an anchor for each auction: Interested parties would then be able to place their bids by signing a transaction that uses both their bid and the anchor as inputs.

When the time-frame of the auction ends, the auctioneer can countersign the transaction with the highest bid, and since the anchor can only be spent once, all other bids are automatically invalidated.

The transactions would have to be posted through the auction's portal, as they wouldn't be relayed by the network without being signed completely. After they were posted though, everybody could verify that they are valid and the bidder actually has the funds.

One problem is though, that bidders could retract their bid, by doublespending the output used for the bid. This wouldn't be so much a problem if only people bid that actually want to win the auction, but would be a very easy way for the seller to push the price up.
In the end, the auctioneer could just sign the next highest bid then though.

The retracting of bids could be monitored by the auction platform, requiring registration.


How do I move the blockchain file location on Windows?

Go to Settings > Options and click the Reset Options Button. Note that this will clear all of the options shown there, so note down what they all are so you can set your options again later.

In the Dialog that appears, click Yes and Bitcoin Core will shut down. Now go to the Bitcoin data directory and copy the entire thing to wherever you want it to be. The data directory on Windows is located at %APPDATA%\Bitcoin. Move the contents of the data directory to the location you want Bitcoin Core's data to be.

Start Bitcoin Core again. You should be prompted to choose the data directory. Choose a Custom data directory and set it to wherever you moved the data directory to. Then set your options again.


Convert a list of 64 hex keys to private import format

You should consider using this (or a similar) python library to import your keys, as straight conversion from hex to base58 can have a few gotchas:

https://github.com/vbuterin/pybitcointools

Check the examples in the README and you should be on your way to making your script.


hmmm, yes, this accounting system within bitcoin :-) bitcoin.SE is full of questions according to the balance on accounts.

The "-17" would indicate, that funds left from a known address in your wallet to an "external" target address. And if fees is 20, then yes, you have "outgoing" 37 coins. Btw: what system are you playing on? Addresses starting with "GPP"...?

When I was playing with the regtest env, I discovered that only "gettxout" provides reliable info, which tx might have funds. See also the thread here.

Here a short linux shell script, to fetch the idea. It needs to get updated to cope with many inputs, so one would need to iterate through the VINs...

  b_cli="bitcoind -regtest"
  FUNDING_TXID=3dda59bf9801f88...5498dd7fd1c3f9577963b94

  TX_PREV_VOUT=$( $b_cli gettransaction $FUNDING_TXID | \
                  awk '/vout/ {  print $2; exit }'    | tr -d "," )

  $b_cli gettxout $FUNDING_TXID $TX_PREV_VOUT

  # as per Pieter's comment, spendable VINs return "something"...
  if [ ${#ret_val} -gt 0 ]; then
    echo " ## This tx has spendable funds"
  else
    echo " ## no spendable funds on $FUNDING_TXID"
  fi

Adding up all the parts, which have spendable funds, would then be "your" balance. And you could check "in" and "out" going funds in your wallet.


How do Blockchain Explorers lookup wallets? [Balance]

There is no way for a block explorer to know which addresses belong to the same wallets, in fact no block explorer shows the balance of wallets but only by addresses.
The only way to know which addresses are from the same wallet is having generated that wallet or having it's seed.
Wallets are a client structure that collects all the addresses for which you have the private key needed to spend, in order to make it easier for the user to have the total balance, but from the blockchain standpoint wallets do not exist, there are only addresses and UTXOs.
If one could know which addresses belong to the same wallet, it would not make sense to use different address for each transaction.


Double spending commonly refers to the situation where you send 1 BTC to Alice but you privately create a fork and on that fork you send the 1 BTC to bob. If your privatefork mines enough blocks to surpass the main fork (i.e you have the majority of hashpower or you are really lucky) you publish it and all the nodes consider it valid since it is the longer chain. As a result Alice loses her 1 BTC.


I'm pretty sure the problem of blockchain.info.

I'm facing the same issue and even though i've tried to set too high fee.

but it seems to be they have some issue and they will fix it soon (as usual).

They're service isn't stable at all. they get this type of issues from time to time and they fix it.


Unable to find peers when connecting through tor proxy

Have you confirmed that tor is working correctly, say with a web browser? Temporarily set it to use a SOCKS5 proxy at 127.0.0.1:9050.

For more verbose information, try starting bitcoin with

commandline:
-debug=1
or
-debug=tor

bitcoin.conf:
debug=1
or
debug=tor


How does blockchain.info detect double spends?

All valid transactions are relayed through the network. A client does not know which transactions will be a part of a block, so it stores and relays both double-spent transactions. If you regularly poll your bitcoind, you can see every transaction before it is put in a block. Then it is just a matter of checking txin data for duplicate inputs.


How does the blockchain prevent spending money during a "short fork"?

Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain

This is incorrect. A block that contains an invalid transaction is invalid, period.

The network's rule is that the longest(*) valid chain is the one to be treated as correct. A chain with any invalid blocks in it is ignored by full nodes on the network.

Now, lightweight nodes on the network do not perform full validation, and thus cannot tell whether the longest chain is in fact valid or not, and thus they'll accept any chain. However, generally lightweight clients are only used by individuals that don't participate in much economic activity. A store that sells real world items for BTC is very much incentivized to use a full node that will never be fooled by this.

Furthermore, since creating a block is expensive, few miners will be willing to produce a block that contains invalid transactions, as such blocks will eventually not be considered acceptable to the network, and thus not result in any income for the miner. This long-term effect that economically-relevant full nodes have on miners through incentives in fact conveys security to lightweight nodes.

  If so, doesn't it make bitcoin transactions slow to process ? I already know that a transaction can be validated by a full node client and that you don't need to wait 10 minutes for the block to be in the blockchain, but if you need 30 minutes to be able to spend the money, doesn't it make transactions slow ?

Unless you trust the sender, you always need to wait for a number of confirmations, as there is always a chance that a (short) non-malicious reorganization of the chain happens, which confirms a conflicting transaction to the one that pays you.

This makes Bitcoin, in adversarial settings, much more appropriate as a settlement layer than as a payment system. And at that, it excels. Compared to say a credit card payment, the receiver knows the transaction is final within hours, compared to maybe months for a credit card payment.

This is an inherent restriction of a public consensus systems: it is inherently hard and slow to get the entire world to agree on an exact state of the ledger. For payment solutions people are building layers on top, which take advantage of the guaranteed settlement, but permit payments in a direct fashion with just knowledge of the involved parties. The Lightning Network is a good example of this.

(*) Technically it is not the longest chain that matters, but the chain with the most work. These definitions are almost always identical, but in the few edge cases where they differ, the difference is important.


What value of nMinimumChainWork and powLimit should I choose for my altcoin?

how to calculate this parameter, i little not understand. It's not block in blockchain, how find this value if altcoin exist end i update sources with exist blockchain end for new blockchain.

Because this is a new chain, the minimum should be zero.

  end about this value , how it convert to diff xxx for understand what diff is it. example diff 1, 20, 1000 etc...

It is diff 1, by definition.


Is it possible that transactions throughput will grow to beyond what can be synchronized?

When a transaction is broadcast to the network it enters the "mempool". Every full node maintains a pool of unconfirmed transactions in RAM memory. Newly broadcast transactions are relayed from node to node through the network.

A typical mining node selects, from its mempool, as many transactions (with attractive fees) as will fit in a block and then attempts to find a valid hash for that block. The first miner to find a valid hash for a block containing a particular transaction will then confirm that transaction.

Any and all transactions not selected for inclusion in a block remain in mempool. A node typically discards unconfirmed transactions from the mempool after 72 hours.

Hence, since memory is limited on most nodes, heavy transaction load can result in their mempool becoming full. This leads to congestion and a slow-down in transaction propagation (through the network) as well as delays in confirmation, since many transactions might not enter the mempool and will have to be rebroadcast by wallet clients until the congestion subsides.

Layer 2 solutions, such as Lightning Network, propose to allow almost unlimited, near-instant transactions per day, thereby mitigating the limited capacity of the Bitcoin network (Layer 1).


Each node checks that a transaction is valid when they learn about it. Nodes check that the used funds exist, and that they have been correctly signed for. You can think of the address as locking the funds to a specific private key. The owner authenticates themselves by using this private key to generate a signature. Private Key and address form an asymmetric key pair, so everyone that knows the address that the funds were previously sent to can verify the authenticity of a signature. Miners then collect transactions, and include them in blocks. When a transaction appears in a valid block, the transaction is considered to be confirmed.

When additional blocks are found, they build upon the longest chain that is known to the mining node. As long as there are only very few blocks stacked on top of the block in chain A that confirmed our observed transaction, there might still exist a competing chain B that could overtake and obsolete those blocks. If B contains a transaction that is at odds with our observed transaction, the observed transaction might yet be invalidated.

Each block, after the observed transaction has been confirmed, significantly decreases the chance of the block being invalidated, because a competing chain has to mine all the blocks since our observed transaction was confirmed, i.e. has to do multiple times the work of the whole network in order to catch up.

When your transaction has been confirmed six times, i.e. five
additional blocks have been found since your transaction was featured
in a block, the probability of a miner with 30% mining power overtaking the current chain tip is less
than 1%, and some consider the transaction to be reliable at this point.

Also see: Is there actual consensus on the blockchain's tip or only until the next block?


What are good ways to storing backup of an encrypted wallet?

You can back it up pretty much anywhere. USB drive, backup hard drive, Dropbox.

If your wallet is encrypted, all they can see is what addresses you own and how many bitcoins they have. They cannot send any bitcoins or get the private keys.


Is there a precise open specification for the peercoin protocol?

Since most crypto-currencies are a fork of Bitcoin, you can get nitty gritty technical details from the Bitcoin wiki, specifically from the technical category.

Say you want to know the specifications for communication, the Protocol Specification article will help you out with how packets should be formatted down to the bit. It will have all sorts of details on things like how to calculate difficulty or what a block chain is.

Peercoin share a lot of concepts with Bitcoin and thus most Bitcoin wiki articles will apply. Peercoin concepts such as its Proof-of-Stake may not be found in the Bitcoin wiki so refer to the whitepaper for differences.


How to track Segregated Witness adoption rates

There is nothing to track until 0.12.2 is released. Once that happens the process is described here:

https://bitcoinmagazine.com/articles/the-segregated-witness-timeline-from-idea-to-adoption-in-six-steps-1461255570

"First, miners (or pools) running Bitcoin Core 0.12.2 (and Bitcoin implementations that merged similar code), automatically start signalling they are ready to mine Segregated Witness transactions. This happens through version bits they include in blocks they do mine that indicate what types of transactions and blocks they can mine.

Once miners representing 95 percent of hash power (1,916 blocks) within a single difficulty period (2,016 blocks/about two weeks) include the right version bit, the soft fork is locked in."

Block explorers will make it easy to track the progress after 0.12.2 is released


Would bitcoin core work on a big endian system? Or even a system where C++'s `int` is not 32-bit?

It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has.

I don't think it will work on systems where int is different than 32-bit.


What happens in detail, when Bitcoin Core verifies a block during synchronization?

Paraphrasing from the Protocol description on the Bitcoin-Wiki:

The following checks are performed on the block:

syntax for correctness
is not a duplicate
has at least one transaction
hash satisfies difficulty statement (nBits)
timestamp is not more than two hours in the future
first transaction is a Coinbase transaction, no other transactions are.
Transactions adhere rules

has inputs and outputs
tx is smaller than MAX_BLOCK_SIZE
each output and the total are between 0 and 21,000,000 bitcoin.

Coinbase's scriptSig length must be 2-100
Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS
Verify Merkle hash of the transactions
Check if previous block is in main chain
difficulty statement (nBits) matches difficulty rules
timestamp is not older than median of 11 previous blocks


searchrawtransactions in bitcoin-cli returning "Method not found" error

There is no cli API as searchrawtransaction in the core bitcoin client. I guess what you are talking about is getrawtransaction. This would be place where you would find all the API's aggregated in one page and you can search for the API you are concerned with.


Bitcoind Cannot assign requested address

First of all check that your system support IpV6.
Run this:

test -f /proc/net/if_inet6 && echo "IPv6 supported" || echo "IPv6 not supported"

Then make sure to bind to ::ffff:0.0.0.0


Lets see, I can't provide you a list with reference, but off the top of my head:

There are blocks that have the same coinbase transactions as previous blocks (I have heard of two, seen one so far)
There are transactions in a block that send a lot of coins to an address of "0" (they were intended for MtGox, but someone made a mistake in their code)
There are transactions that have multiple opcodes for verifying signatures
There are a lot of transactions that put some data on the stack and get rid of it
There are transactions that use other verification methods than signatures (for example, passwords)

Those are to my knowledge the cases that could cause the most trouble for poorly implemented clients


Why the timestamp component of the block header?

The timestamp exists so there will be a permanent record of when the block was found. The timestamp needs to pass some sanity tests for the block to be considered valid.

One of the key uses of the timestamp is in calculating difficulty retargets.


getting the unspent bitcoins based on bitcoin address

The easiest way would be to use the API of a block explorer. Several provide such an API and some have wrapper libraries for C#.

For example the blockchain.info blockchain explorer has such an API and has a C# wrapper as well. Consult their Blockchain Data API which explains how to get the balance (among other data) from an address. More specifically, you need to call the following (HTTP) API:

https://blockchain.info/address/$bitcoin_address?format=json

The result is a json object and "final_balance" is what you need.

If you use the C# wrapper you can find an example on how to get the balance of an address (and many other things) here.

Alternatively, you could query a bitcoin node directly. The easiest way to do that in C# would be to use a wrapper library.


In case of the Bitcoin split - when holding BTC on blockchain.info - will I receive coins on both forks?

Yes, blockchain generates address deterministically as per BIP 44, and uses mnemonic backup phrases as per BIP 39, so you can recover all your keys using that mnemonic. It is compatible with any other wallet which follows BIP 39 and 44, and because it allows you to regenerate your private keys, it is equivalent to backing up the keys themselves. So you should be safe.

References:

https://support.blockchain.com/hc/en-us/articles/115001298143-Your-Recovery-Phrase-The-Failsafe


How does Bitcoin Gold difficulty adjustment work?

It's just a simple moving average with a window of 30 blocks:
next_D = sum(past 30 D) / sum(past 30 solvetimes) * 600

This isn't exactly what it's doing, but it's darn close.


Bitcoin-cli 0.19.1 Wallet not Sending from Addresses with Closest Amount?

I am not sure why coin selection algorithm didn't work or if you manually added some inputs or could have manually added inputs to avoid this. However, you could have still avoided paying more fees.
The transaction had virtual size of 78213 VByte
You had used fee rate: 46 sat/vByte
Since this transaction involved lot of inputs and bigger size, you could have used a lower fee rate when mempool had less than 5 MB of transactions.
Assuming you had used 5 sat/vByte fee rate for this transaction, the total fees paid for the transaction would have been 0.0039 BTC which is 90% less than the fees you paid.
Looking at the mempool history, the transaction would have confirmed yesterday:

UTXO consolidation is normally done when mempool is clear or you have lots of time so that 1-5 sat/vByte can be used for such transactions.
Consolidation of 4 Million UTXOs at Xapo: https://bitcoinops.org/en/xapo-utxo-consolidation/


Why is my client software not receiving bitcoins?

There are a few things that you should check:

Your client is connected (it shows N connections in the status bar). If it doesn't, you have connectivity problems.
You have downloaded the whole blockchain (the N blocks in the status bar is not increasing rapidly). You need to wait until you have downloaded all blocks.
Blockexplorer can tell you if the payment has been sent to your address. Just type your address in the search box. If it doesn't show up in there, it's because it wasn't sent yet.

These websites give very small amounts of money for free so they usually group transactions (instead of making many small ones). You probably need to wait a while before the payment is sent.


The getwork RPC call was removed from Bitcoin Core. It was deprecated and then superceded by the getblocktemplate RPC call.

It looks like the pool that you are using uses an unspecified protocol. It's just a tcp connection where you are sending JSON formatted strings and receiving JSON formatted strings from the pool server. I figured this out by digging through this mining software's source code.


Often these CPU miners are flagged by specific AV's heuristics, mainly because the program may be an exe with a hidden CPU mining algorithm within, which if it was any other exe like an image viewer, this suggests nefarious mining.

That being said, altcoin wallets and miners are notorious for malicious code, and Bitcoin is the target of more than 100 types of BTC stealing malware.

Since cgminer/cudaminer uses scrypt-n simply find a miner which has been vouched for (ie checksum of the exe should match).


How is scalability of walletnotify of the full node wallet

Using walletnotify has proven to work and is used by a lot of scalable apps today. I would not rely on it completely though. walletnotify's job is to execute a shell command every time it receives a wallet transaction. This means data is flowing between processes, which does not make me entirely comfortable as a developer. After all, it only takes one error for someone to be missing their funds.
I would recommend not only using walletnotify, but to also check X blocks after Y minutes. You can keep track of blocks passed and if any transactions were not processed by walletnotify, your cronjob of checking transactions will recover the transaction. You can use listsinceblock RPC command and keep track of the block height each time you check transactions. You could store transactions processed in a DB somewhere.
After all, this is a financial application so I think a backup check is vital.


If your node received the original spend, the listunspent RPC will display the transaction with "-1" confirmations, as will any other RPCs that would normally list the transaction.  The source code calls this conflicted: "not in the mempool and not in the block chain."  This feature was first included in 0.9.0.

If your node never received the original spend (perhaps because it was offline at the time) or the now-stale block that contained it, it doesn't have any way to know about that original spend, so there's no information you can get from an RPC.


fundrawtransaction causing bitcoind 0.17 to crash

This is a known crasher in 0.17.

You need to either:

downgrade to 0.16.3
apply the patch given in the pull request and build Bitcoin Core yourself
wait until 0.17.1 is released to fix the issue.


Submitting an old balance sheet in the lightning network

This "balance sheet" is a Bitcoin transaction which spends a 2-of-2 multisig input and creates 2 outputs, one to each party. The outputs have each party's respective balances. It is known as the commitment transaction.

However, both parties do not have the same transaction. Rather, what they have are different transactions that have different scripts for the outputs, so there are different conditions for spending the outputs.

So for each person in the channel, they have an output that pays the other person, and an output that pays himself. The output that pays the other person can be spent by the other person immediately if this transaction were broadcast. However, the output that pays himself has a special condition: prior to some time delay, anyone who has a specific revocation key can spend the output. After the time delay, either of the person himself or person who has the revocation key can spend the output.

This revocation key is something that the other person in the channel learns when a commitment transaction is revoked and replaced with a new one that has new balances. It is learned in a way that is guaranteed to be atomic, i.e. the revocation key and the new commitment transaction are given by both parties to the other party at exactly the same time, guaranteed (there's some cryptography involved that guarantees this).

So if one person were to broadcast an old commitment transaction, then he would not be able to access the money until the time delay expires. However, during that time, the other person in the channel who now has the revocation key can use that revocation key to spend that output and take the broadcaster's money. So the penalty for broadcasting an old commitment transaction is to lose all of your money.

The blockchain and miners are not involved in this whatsoever. It is entirely based on scripts in the Bitcoin transactions and the ability for the other party to react in time.


How can I set up a simple single page store that accepts Bitcoin payments?

If for you it's ok to use 3rd parties' services, a simple google search will present to you several plug-ins that suit your purpose.

If you want to do it by yourself, here is how you may want to tackle this endevour:

you must have an HD wallet (aka deterministic wallet compliant with BIP 32).
you put your XPUB in your server and you use it to generate dynamically the public keys that will be shown to your customers.
You want to make sure that every customer sees a different public address, so that when you receive a payment you will know who paid for what. If you always use the same public address (besides compromising the privacy of all parties involved in the transaction) you won't have any way to know which customer paid for what product. More on this point later.
in HD wallets new key pairs and public addresses are generated using the XPUB in conjunction with an HD path such as this: M/44'/0'/0'/0/x. Every time a new customer sees the payment page , in order to show him or her a new address, you need to change the 'x' (child) value. For example the first customer will see an address which corresponds to HD path M/44'/0'/0'/0/0 , the second customer will see the public address which corresponds to M/44'/0'/0'/0/1 and the third one will see M/44'/0'/0'/0/2 and so forth. You can go on for millions of addresses, but you need to put in place some mechanism that allows you to keep track of the last child number. You can do that on a JSON file on your server or through your DB.
if you want to apply some sort of automated business logic you need to monitor the blockchain to listen to incoming payments to the addresses you created. Sure enough, purchase data must be saved into your DB along with the bitcoin public address created for that specific purchase. This will come handy later when you will need to automatically  confirm the purchase to the customer and deliver the order.
You may want to use a websocket to listen to unconfirmed payments (in mempool) received by the address shown in the webpage that the cusomer is seeing. As soon as a payment is detected , with a dozen lines of JS you ll be able to print a "thank you" message on the customer's screen.
Monitor the blockchain for confirmed payments (at least one confirmation, but 3 confirmations is safer) received by the addresses you generated. When you see a new confirmed payment you can confirm the purchase to the customer by email and ship your product to him or her.

As a final piece of recomendation, you should set up some sort of count down or other mechanism that limits the validity of the address you generated and prices quoted. This is vital to protect yourself and your customer from the tremendous price swings of BTC against major fiats.

I hope that this helped you :-)


Sudden Drop in Hash Rate GeForce 650 GPU Card

I think I figured out my own issue here.  I reset the SMC on the macbook (http://support.apple.com/kb/HT3964) and my GPU performance is back to normal.


There are many blog posts, howtos, etc. available through Google which will tell you know to mine your favourite crypto currency using an NVIDIA GPU on Linux.

Please note that NiceHash is something similar but different. NiceHash is an online marketplace for hashing capacity. It is not a mining pool. NishHash is about renting out hashing capacity to people who think they know how to get back more rewards from using X amout of hash than they have to pay for it.

AFAIK NiceHash does not offer a Linux client. Did you try to run it in a VM or on Wine?


What is the best practice for listening to payments on the RPC api?

Bitcoin has walletnotify feature that will notify you when an address you own in your wallet receives a transaction, and a second notification when the transaction confirms.

You can set it in your bitcoin.conf

walletnotify= curl http://yoururl.com/endpoint.php?tx=%s

%s will contain the transaction id. What you do from there is up to you.


How to calculate the Public key P2SH from hexadecimal script?

This is specified in BIP 13: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki

You compute the Base58Check encoding of the P2SH version byte (5 for mainnet, 196 for testnet) followed by the 20-byte Hash160 of the script.

The code you're quoting is for P2PKH addresses, not P2SH.


Why are most Bitcoin payment invoices time limited ?

Most invoices are timed to ensure the price of bitcoin (or any crypto asset) does not move too much.

Although Bitcoin is usable as a currency, it's current volatility is somewhat undesirable. Timed invoices are used to ensure that merchants get a roughly expected $ value.


10$ registration bonus on Coinbase : how to get it?

Ok, I found it : you get the bonus when you buy or sell 100$ of bitcoins, ethers or litecoins on Coinbase.

:)


transfer funds from Mt.Gox after the crash of 2014

Short answer: No.

MtGox assets are currently frozen and they have lost a lot of customer funds, both fiat and Bitcoin. Until further notice you can consider your euros lost.

Contact your lawyer and ask them to write a claim to official MtGox address. Also some local Bitcoin communities are preparing class-action (or similar) lawsuits against MtGox and its subsidiaries.


Could a Multi-Chain Bitcoin Help the issue of Scaling?

No, I don't think that sharding is as simple or beneficial as portrayed here. Here are a few thoughts:

Splitting by addresses doesn't seem plausible. Most transactions have either multiple inputs or multiple recipients. It's not clear how transactions would be handled that attempt to spend funds from both chains or pay to both chains. If they need to be present on each chain, I don't think we'd get a significant traffic reduction on either chain. If they do get included on both sides, how do we ensure that they don't get confirmed on only one side? If they can only be included on one side, how do we coordinate that?
ETH has been working on Sharding since 2016(?), and as far as I can tell, it requires layers of mitigations and complexity, and comes with all sorts of trade-offs. ETH requires global state for each transaction's execution. By introducing sharding, ETH gets multithreaded validation. Bitcoin's transactions are inherently stateless, and its scalability concerns are related to total resource usage. Two shards of 0.5 MB blocks are no better than one chain with 1 MB blocks for that. Two shards with 0.5 MB blocks that have a storage footprint of 0.75 MB and coordination overhead sound like a step back.
It sounds like a complete consensus overhaul. It's unlikely that people would be comfortable to support such a proposal.

That said, we already have some sidechains and second layer solutions that we can offload transaction traffic to with far less overhead or critical changes.


Is it possible that malicious bitcoin wallet providers provide pre-generated private-keys for users?

You can verify the legitimacy of Coinkite's Coldcard key generation, assuming that you've used Coldcard's feature of generating the entropy for the seed words by throwing dice (the key generated will be based on your dice throws and so wasn't surreptitiously built into the card).
The web page https://coldcardwallet.com/docs/verifying-dice-roll-math gives details on how you can verify that the Coldcard honestly generated your seed words and key from your dice throws.
I should mention that I haven't actually carried out the verification, but it looks doable.  (Just be sure that you never enter the dice throws, seed words, private keys, etc., on any Internet-connected device, and never attach the Coldcard itself to the Internet or to any Internet-connected device.)


Get single xpub key from multi signature wallet

No, it's not possible to get a single public seed for all future addresses.

Let's say you have three private seeds, Sa, Sb and Sc with public seeds (xpubs) Pa, Pb and Pc that generate the addresses Px1, Px2, ...

Then, the way to calculate the multi-sig addresses for a 2-of-3 multisig for these three seeds using P2SH is the following:

You create a P2SH redeem script that looks as follows:

OP_2 [Pa1] [Pb1] [Pc1] OP_3 OP_CHECKMULTISIG

Then, the "multisig address" is the RIPEMD-160 hash of that script.

Thus, to know the next address, you will need to calculate a new RIPEMD-160 hash with the script now containing Pa2, Pb2 and Pc2. There is not a multi-seed of any kind.


Determining xprv from xpub and child private key

This recommendation comes directly from one of security considerations from the same document:

  Note however that the following properties does not exist:
  (...) Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.

The reason for this recommendation is the fact all the non-hardened key derivation bases on some of the elliptic curve properties. One of them is that you can add some number to private key (which itself is ordinary number). When you convert the same number to the point on elliptic curve you can add it to public key (which itself is the point on elliptic curve). This new private key is exactly the private key for the new public key.

The problem is that this number we add  (parse256(IL)) can be calculated from parent public key and parent private key.

So, if we know the child private key kchild and before mentioned number parse256(IL) (which we know, because we know parent public key), then we can rearrange the equation from which this key was derived:

kchild = parse256(IL) + kpar (mod n)

and find kpar which is the parent private key.


Does cryptocurrency ETF use block-chain technology?

Is it necessary to build [Exchange Traded Funds] over block-chain technology?

No.

in case the answer is no, why?

Imagine an ETF based on stocks in gold mining companies. Those companies own open-cast mines and rock-crushing machines.
An exchange can buy and sell shares, or funds based on those shares without directly themselves operating any open-cast mines or rock-crushers.
Rock-crushing machines are not suited to keeping track of sales and purchases of stocks and shares, or of funds based on them.


Why are the drops in mempool unconfirmed transaction count not of constant height?

A transaction is not a fixed size. Removing one large one will have no impact on the count, but removing ten thousand small ones will.


Signing transactions can not find private key

I've been using Electrum wallet since.
I'm trying to explain my situation better.
So this is where it starts this is my cancelled order. I've redacted parts of them, but you hopefully get the idea.
My order site has refund information as you can see from the picture. So what I did last time was using coinb.in and it worked. I copy this
code of numbers given to coinb.in.
https://postimg.cc/34wht4xM
Coinb.in recognizes the transaction. The address I used with my Electrum wallet is there.
https://postimg.cc/grq5xkz8
The next step is to sign the transaction with my private key. I remembered I have a file saved on my computer with my private key information. I have saved my private key and all PGP key password information on my computer and been using this the last 3-4 years. So I opened it and used the private key to which it wasn't recognized.
This is my saved private key information.
https://postimg.cc/bG9Csm88
Previously on the vendors website I'd save my bitcoin refund address and public key. The public key matches, but the address is different, because the new Electrum I updated in the past changes my Electrum receive address.
https://postimg.cc/62DYPgfr
Anyway, when I enter the private key from my saved note the following occurs:
https://postimg.cc/627MYtn6
So then what I did was I looked up all my addresses on my Electrum wallet and I found the one I did the transaction and it has the private key next to it like in the picture here:
https://postimg.cc/3kK9zgmc
I typed in this private key, but I still can't verify:
https://postimg.cc/627MYtn6
So my bitcoins are stuck now and I don't know what to do how to get them back IF.....
I hope I've explained myself better. What do you think I should do now?


How can you find out what is the latest block number?

All these sites display the total block count:

http://blockexplorer.com/
http://bitcoincharts.com/
http://bitcoinwatch.com/

BlockExplorer also has an API that among other things lets you get the latest block count.


Can a created segwit address match a non-segwit vanity address?

yes, it is possible. i can create such prorgam for you, but without GPU acceleration it will run too slow


How do I connect my online store to the blockchain?

If you want to accept payment by Bitcoin or Bitcoin API in your application then you can use "blockchain.com" 's API in your application. So that you can build function and module as per your requirement and also if you want to build your eCommerce platform from scratch then you can use "CryptoWoo.com".


Update the software first. Both Bitcoin Core and Armory. Most likely no need for new hardware.


I have one observation, not sure if this leads to the error. Multisig scripts start with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-)
Looking at your tx, I see the third signature doesn't have this zero:

TX_IN[0] Script Sig (uchar[])
1) 0047304402206558714362318FF5AA05BD1849B82726F4D3AB2545BC15379B73DE1FCA4EF6C002206EA00F130EA54D6E85F233A3D031BDF03D35A10319362FE41866D5C59C7D7B1B01
2) 00483045022100B9DAEA5E3DA41E305B2A283825C45C7EEF169364413AF043115797124033F1CE022004AE32ECAB1937FAC90E904BE684F893CCDD1D925D6B898AEF7F275DCB9791EA01
3) 483045022100E54C2F805C5BA5025C375053C4604910A30E5BF86EB16A5C9BA35CD9F817AEF802201F92DA76CF31562AE28E527BD537ECF930139224A8D91D10886383958AADD6BD01

which is disassembled sig1:

    00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
    47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
    30: DER_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    44: DER_LENGTH_0x44:      length of R + S
    02: DER_INT_0x02:         type tag INTEGER indicating length
    20: DER_LENGTH_0x20:      this is SIG R (32 Bytes)
        6558714362318FF5:AA05BD1849B82726
        F4D3AB2545BC1537:9B73DE1FCA4EF6C0
    02: DER_INT_0x02:         type tag INTEGER indicating length
    20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
        6EA00F130EA54D6E:85F233A3D031BDF0
        3D35A10319362FE4:1866D5C59C7D7B1B
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

and sig2:

00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: DER_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: DER_LENGTH_0x45:      length of R + S
02: DER_INT_0x02:         type tag INTEGER indicating length
21: DER_LENGTH_0x21:      this is SIG R (33 Bytes)
    00B9DAEA5E3DA41E:305B2A283825C45C
    7EEF169364413AF0:43115797124033F1
    CE
02: DER_INT_0x02:         type tag INTEGER indicating length
20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
    04AE32ECAB1937FA:C90E904BE684F893
    CCDD1D925D6B898A:EF7F275DCB9791EA
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

and sig3:

48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: DER_LENGTH_0x45:      length of R + S
02: DER_INT_0x02:         type tag INTEGER indicating length
21: DER_LENGTH_0x21:      this is SIG R (33 Bytes)
    00E54C2F805C5BA5:025C375053C46049
    10A30E5BF86EB16A:5C9BA35CD9F817AE
    F8
02: DER_INT_0x02:         type tag INTEGER indicating length
20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
    1F92DA76CF31562A:E28E527BD537ECF9
    30139224A8D91D10:886383958AADD6BD
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)


Buying from country A, selling in country B

Sure it's legal. Unless either country has outright banned buying/selling Bitcoins. I don't think there's any country that has gone that far.

You may have to report income/profit/trades to your tax office, depending on local laws. In some countries you may need to pay VAT as well.

Setting up accounts with (foreign) exchanges means that you are entrusting them with your bitcoins, money and ID (copies of passport etc.). Exchanges disappear overnight sometimes, so make sure to put that into your risk calculation.

Sending Bitcoins around the world is pretty much instant. Exchanges require up to a few hours of confirmations sometimes, but that's still nothing compared to sending your fiat money around the world through the banking system: that can take weeks and cost you many percentages. To/from some countries it's even almost impossible to send/receive fiat money (China comes to mind).

All this means that Arbitrage is not as easy as it seems and that's why there's still a price difference.


How come importing the bootstrap.dat to Bitcoin Core takes so long?

When you bootstrap the database of your Bitcoin Core, the bootstrap.dat contains all the data necessary to build the database, but your computer will still build the database from ground up, verifying each and every transaction of each block. So, compared to the regular synchronization you just save the downloading of individual blocks. Once the bootstrap.dat is renamed to bootstrap.dat.old it has been completely imported and can be safely deleted.

Now, in your case, the bootstrap.dat was probably a few weeks old, and your computer is getting the remaining blocks through regular synchronization. It will download one block, verify all content, update the database, and repeat, until the it has caught up to the current state of the network.

For the whole process the bottleneck is usually the CPU, as it's mostly computation, or the harddisk i/o. The necessary download speed is much less than 50mb/s, though it is quicker in total if all data is already available on the computer. It is common for this process to take hours to days.

As Jannes and David pointed out in the comments, synchronization performance will generally be improved with the upcoming 0.10 version due to the introduction of headers-first synchronization.


What I'd suggest is to convert it to USDT on Bittrex or Bitfinex and then proceed to withdraw USDT to your bank account.

Another alternative is to convert it to BTC and withdraw it in cash using Localbitcoins.


signrawtransaction - Which private key from BitAddress.org?

Ok.....

Since nobody answered. After smashing my head against the wall for a day, I finally figured out that since I am developing right now, and I am using testnet, the private keys generated for testnet and the private keys generated for "real net" are not interchangeable. So I had to switch BitAddress over to testnet mode to get keys that would work for my transaction.


Why isn't the description field synchronized at different Electrum wallet?

A Bitcoin transaction holds no Metadata beyond what is required for moving coins. Any descriptions, labels, or other such information is purely handled by the wallet, and synchronizing it is up to the wallet.

Electrum does not synchronize any such data, so you will only see it on one device.


I am new to Bitcoin.

Welcome !

  I have downloaded the whole blockchain but I still can't access my wallets because I get a popup telling me to use prune mode.

You might not have enough disk space (hence why you're not able to see your funds).

  If I run prune mode, will I lose those deposits since they are not yet in my wallet?

No, not at all.
By using prune mode you'll be able to fully sync to the tip (current last block of the chain) and thus see your funds, which you apparently cannot without prune mode because of your disk space.


What is the equivalent of cold storage or paper wallet for NXT?

It is possible, but quite more difficult than with Bitcoin.

All NXT tokens/coins are stored on the network, but it is possible to create an account "offline" that is secured by a 256-bit public key and does not expose your private key to the network.

There is a step-by-step tutorial on the NXT-Forum.


If I am spending multiple inputs from the same address, must I provide a signature for each input?

Do I need to provide a signature script for each input that proves that I own it?

Only signing and checking signatures once for each public key, assuming signed with SIGHASH_ALL, seems like it would be safe, but I don't think there's any such optimization in the bitcoin code. If something was signed with SIGHASH_SINGLE, though, then it wouldn't be okay to assume that the owner of the key approves of all other outputs too.

  Wouldn't that waste space?

Yes, and signatures are the largest single component of a bitcoin transaction, so it's a non-negligible space too. At the same time, though, spending from two UTXOs that were sent to the same address probably isn't the most common type of transaction.

  Also, in the standard client, are the signatures exactly the same, or are they two different but valid signatures?

Looking at the SignatureHash code, the input scripSigs are all emptied and then only the one corresponding to the input that is being signed is filled with the previous scriptPubKey (for somewhat strange reasons).

// Blank out other inputs' signatures
for (unsigned int i = 0; i < txTmp.vin.size(); i++)
    txTmp.vin[i].scriptSig = CScript();
txTmp.vin[nIn].scriptSig = scriptCode;

This makes it so that the hash that needs to be signed (the result of SignatureHash) is different for each input. Thus, since different data is being signed, the signatures will most definitely be different. Even if the data being signed were the same, ECC signatures are non-deterministic (involving a random number) and so will not be the same from signing to signing.

EDIT: The long and short of it is that the double hash that needs to be signed is different for each input in the new transaction, so even if the same key pair is being used, a new signature must be calculated.


I have forgotten my Blockchain account password and 12 word recovery. I have the wallet id and password to the wallet. Can i get my funds back?

If you have a custodial account with Exchange.blockchain.com, you must contact them for help. They own the money, not you ("Not your keys -- not your bitcoin").
If you have a non-custodial wallet downloaded from Blockchain.com, you should normally recover control over your money by restoring the wallet from a backup or from a safely stored record of either the recovery-phrase or the private-key. If you have none of these, you have lost control of the money.

References

Blockchain.com custodial account
Blockchain.com non-custodial wallet

Write Down Your Backup Phrase
Your backup phrase is the most important of all security measures. It is the key to ensuring your access to your funds if you forget your password or Blockchain is unavailable.


How do APIs like Blockchain.info and BlockExplorer work?

Public Bitcoin inspection services like BlockExplorer and BlockChain.info work almost exactly like the regular Bitcoin client.

They operate as a node in the Bitcoin network and so, like all other nodes, store the complete block chain. This block chain consists of all transactions ever made and are used to calculate the balance of an address.

Just like other nodes, they as well receive transactions from other nodes and will likely also show them before they are confirmed (of course explicitly indicating they aren't). The time it takes for a transaction to reach all nodes varies. Not all nodes know about all other nodes so it can take a few seconds for a transaction to get noticed by all nodes.

Depending on whether or not the service caches information, some time can be between the arrival of the transaction of the node and the time it shows up on the website. You will probably understand that when you query 10 times shortly after each other for the same data, it is very costly to do the same lookup in the block chain index multiple times. Because of this, I think it's likely that most of these clients do some sort of caching, but not too extensive. Probably a minute maximum, because they know that in Bitcoin transaction processing, much can happen in that time.

Besides that, the loading time can also depend on the load of the server. When multiple users try to access the balance for their address at the same time, some of them will likely have to wait.


Why does vanitygen warns me to update an up-to-date OpenSSL?

You might want to try WyseNynja's Homebrew tap, you can then install vanitygen with better dependency handling.


Bitcoin RPC getbalance of address I sent coins to on regtest

getbalance returns the balance of an account, not an address.  https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

If there's no account by the name of mvt7M16caMH1xoJyfWU5orjArfq97jhZ7k, it will return 0.

Try using getreceivedbyaddress instead.


Why doesn't Bitcoin Core use Google's OSS-Fuzz?

The primary reason that Bitcoin Core doesn't use OSS-Fuzz is that as Greg Maxwell states in this secp256k1 issue, there is an:

extremely short timeframe mandatory disclosure (edit: 90 days) which basically made
anything except blindly installed automatic updates a viable way to
deploy fixes

Pieter Wuille adds some additional context here:

This extraordinary requirement for exact consistency between implementations means that these classes of issues cannot be fixed in the time scale of software releases, but requires network-wide coordination. The most relevant example is how a platform dependent deviation from the DER standard in OpenSSL threatened a network split a few years ago; you can read about the issue and its timeline here. In that case, it took 9 months between discovery and eventual resolution, but I believe that similar issues these days would take significantly longer still.

Without a future exception granted by Google, Bitcoin Core using OSS-Fuzz is a non-starter.
I am less clear on exactly how much additional value Bitcoin Core would get from using OSS-Fuzz in a theoretical world where Google granted that exception. It is partly discussed in the issue in addition to the current state of fuzzing in Core and the secp256k1 library.
There is also the consideration of dependence on a specific corporation's infrastructure. Open source projects aren't locked in to OSS-Fuzz but it is generally time consuming and disruptive to make the transition off of them.
Update on May 5th 2021: Bitcoin Core has signed up to use Google's OSS-Fuzz.


Can a Bitcoin transaction have the same address for input and output?

At the protocol level, there is no such thing as "balance of an address". There are individual unspent outputs (like coins in a wallet), which must be individually spent. You can't partially spend an output, but you can split/combine it.

So for example, you have a 70 BTC output assigned to an address, and a 80 BTC output assigned to the same address. Some software will show this as 150 BTC balance of that address, but you still need to know the individual outputs to spend them. If you want to send 100 BTC to someone, you would consume those two outputs in a transaction, and create two new outputs using it, a 100 BTC one (to the recipient) and a 50 BTC one (back to yourself).

Whether you use a new address for that 50 BTC "change" output doesn't matter to the protocol. You can reuse the old one, but will make it obvious to everyone in the world which who was the sender and who was the recipient in the transaction. Using a fresh address improves privacy.

Seen otherwise: reusing the same address may look convenient, as it allows you (and software you use) to more easily distinguish what your balance is, but it does this at the cost of making it obvious to everyone in the world. This hurts Bitcoin's privacy - not just yours, but that of everyone in the system.


How does BitPay detect unconfirmed transactions so quickly?

That is feature of Bitcoin node network.

When your client sends your transaction to network, every node is also sending your transaction to every other connected nodes. In about 5 seconds it is broadcasted in every place in world.


Using mining pools, how do miners switch what coin to mine so quickly?

how do miners switch what coin to mine so quickly

This is called profit switching, and is usually implemented by the pool software. For example, NOMP explains this feature:

  Coin-switching ports using coin-networks and crypto-exchange APIs to
  detect profitability. Miner's connect to these ports with their public
  key which NOMP uses to derive an address for any coin needed to be
  paid out.

See https://github.com/zone117x/node-open-mining-portal

  Also do miners store a copy of the blockchain locally?

Typically, no. Miners focus their resources on the hashing algorithm and implement minimum necessary data transfer. Nodes store and validate the data and the miners will just get the latest block template from the node to mine, and then send solutions back.


The getnewaddress command will create a new private key/address and associate this with the default account, which is "" (has no name).

You can assign private keys to different accounts by naming them, and if you used:

bitcoind getnewaddress "account1"

This would create a new private key/address for the account "account1". This doesn't create multiple wallet.dat files, just different accounts.

You could store all the keys in the bitcoin core wallet and have each web users "wallet" be created as a different account in bitcoin core.


On a low level, how are long chains kept secret and later broadcast during 51% attacks?

When I feel like it, I can then broadcast my chain (which is longer than the trusted chain), which will nullify all transactions starting from block n+1 inclusive (is this correct?).

Yes, it's correct.

  Firstly, on a semi-low level (i.e. in terms of actual data/file operations), how does one keep and cultivate the secret chain?

The same way your node stores regular blocks.  To build your separate chain you can, as you suggest, just disconnect your node from the regular network.

  Secondly, how does one broadcast the bigger chain?

Just reconnect to the network.

  My understanding is that when you connect to the network and submit a block at height k, it will be rejected if the main network is already on block k+1 or greater. So even if I sequentially broadcast my solutions, wouldn't they be rejected before it could be revealed that the number of solutions I have exceeds that of the main network's chain?

When you reconnect your node to the network, it will establish new connections with new peers and they will exchange messages that say, basically, "what's the best block you know of?".  The other nodes will tell you about the weaker public chain and you'll tell them about the stronger formerly-private chain.  The other nodes will then request all the blocks for the stronger chain and your node will relay them.

As a practical example, during the consensus failure fork documented in BIP50, this is exactly what Bitcoin Core 0.8.0 nodes saw happen.  They followed the strongest chain, which became longer by more than a dozen blocks, but then miners shifted to working on the weaker chain and made it the strongest chain.  The 0.8.0 nodes followed suit just fine.

Something similar happened with the 4 July 2015 fork with most pre-Bitcoin 0.10.0 nodes.  They saw what looked like a valid chain with +6 blocks, but then another chain was extended to become strongest and they switched without problems.


testnet.blockchain.info api not showing latest results?

I noticed a few weeks ago that the URL https://testnet.blockchain.info now redirects to the main BTC/BCH/ETH explorer page. The whole site has a new look, and new coins.

If you search for the address via the web interface, you can see the testnet transaction: https://www.blockchain.com/btctest/address/mzWCWQU6phb9rKSAiQ4FBU92sGYtY7tjPH

Given the recent changes, is it possible they just haven't yet changed over the API for testnet?


With my only knowledge of the concept of "antifragile" being the slideshow I just read, my initial assessment is yes, Bitcoin is antifragile.

  Antifragile benefits from randomness and gains from disorder.

Randomness in Bitcoin appears in the random generation of keys and in the whims of its users' spending habits. No one person controls the system, and a transaction may or may not get processed based on connectivity and fees. There is an incentive to connect to as many nodes as possible in order to broadcast a transaction.

In Bitcoin, anyone is allowed to participate, because no one is prohibited. Participation may be cost-prohibitive now, but as time goes on, it won't be.

There are stressors on the Bitcoin ecosystem: block chain dust, nodes disappearing, nodes flooding transactions, etc. None are as close of a match as sudden jumps in hashrate and the subsequent adjustment to difficulty. Too much of a jump, and the "body" breaks: someone gets a 51% attack going. But, enough of a push and the difficulty increases, making it harder to break that 51%. Also, if the body hasn't been used enough - there hasn't been a high enough hash rate to produce the expected number of blocks - the difficulty lowers in order to allow more blocks to be found.

Thus, the Bitcoin system adjusts to its environment. Moreover, it does so in a chaotic way: there are rules set in the protocol, but those rules can be change if a majority of participants in the system agree to change the rules and agree on a new set of rules. In the absence of Internet, Bitcoin transactions can propagate through sneakernet or through even basic text format printable on paper.

Moreover, given the randomness of human economic behavior and the external environment which Bitcoin uses to propagate, various edges and remote notes of the network graph may have sudden activity that the rest of the network doesn't see. The rest of the network has to deal with that activity or risk invalidating itself.

Slide 40 is one where Bitcoin really is antifragile:

  Complex systems resist top-down design, and oftentimes even top-down interference. This is because these systems are simply too complex to be controlled from the outside.

Bitcoin is resistant to top-down design now because of the number of people using it and processing its transactions. Gavin Andresen could not suddenly make a change, because 51% of the network hashrate would have to agree with his change. No one can interfere, only vote to support or not support a given transaction by directing their miners to include or not to include a certain kind of transaction in the blocks they produce. Moreover, Bitcoin cannot be controlled by anyone except participants in its ecosystem (not matter what governments might think or try to do!).

All participants in Bitcoin have a skin in the game. By processing transactions, they in turn process their own transactions as well as the transactions of their peers. If they can get 51% of the miners to act a certain way, then that's the way the economy goes.

So, yes, I believe that, based on this slideshow, Bitcoin is antifragile.


difference between litecoin and bitcoin transaction id format

They do not overlap. A transaction is always unique. a cryptographic hash algorithm is designed in such a way that they do not collide. This is one main requirement  of a hash function.

The inputs to create the transaction ID is partially based on the inputs which are being used to create the actual spend request in the chain, thus you will never have a collision between Bitcoin and Litecoin.


Sure :)

My solution was pretty simple:

//String to a private key
DumpedPrivateKey dumpedPrivateKey = DumpedPrivateKey.fromBase58(params,
        privKey);
ECKey key = dumpedPrivateKey.getKey();

//String to an address
Address address2 = Address.fromBase58(params, address);

Transaction tx = new Transaction(params);
//value is a sum of all inputs, fee is 4013
tx.addOutput(Coin.valueOf(amount-4013), address2);

//utxos is an array of inputs from my wallet
for(UTXO utxo : utxos)
{
    TransactionOutPoint outPoint = new TransactionOutPoint(params, utxo.getIndex(), utxo.getHash());
    //YOU HAVE TO CHANGE THIS
    tx.addSignedInput(outPoint, utxo.getScript(), key, Transaction.SigHash.ALL, true);
}

tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
tx.setPurpose(Transaction.Purpose.USER_PAYMENT);

System.out.println(tx.getHashAsString());
b_peerGroup.GetPeerGroup().broadcastTransaction(tx);


Why does Electrum's SPV require proprietary servers?

Quoted directly from the source:

  One security advantage of Electrum is that servers are authenticated
  using SSL; this provides protection against MITM attacks, which is a
  problem for thin clients, including bloom filter clients. However,
  this advantage comes at the cost of  privacy, because the main
  Electrum server you use knowns which addresses you are using; bloom
  filter clients have more privacy although the default setting in other
  clients is to favor speed at the expense of privacy.


How relative can be "Blockchain" and "Social Network Applications"?

I think you have pretty much answered the question yourself. The only use case I can think about for implementing social network on a blockchain is if you are hosting content that is illegal (connecting the likes of drug dealers, child porn makers etc.). In that case you can be assured that since there is no single point of failure, the law enforcement agencies cannot shut you down. Consider Silk Road Dapp on Ethereum. For all other use cases, it is redundant.

The current hype of putting everything on the blockchain is a gross neglect for the basic engineering design principles. Blockchain has a very specific use case: Ensuring transactions are valid and no double spend occurs. It should not be used to store your house land record, your marriage certificate or how many times you shower in a day. As you store more and more redundant data on the blockchain, it would get so bloated that a normal user would refrain from running a full node. What's the point of calling your blockchain as a decentralized system then?

As far as my interactions go with normal people, they do not mind seeing advertisements next to their social media feed. Some just block it off with ad-blockers, other love the recommended shopping lists it shows them. The mere concept of paying $0.1/tweet is absurd and pointless. You can build pretty elegant software solving the real life problems that are currently being faced by people. Putting everything on blockchain is definitely not what is going to solve them.


Public Keys Prefixes and Derivation Paths

It all depends on the wallet. There is no rule saying they should even accept these strings or know what they correspond to and there is no consensus among wallets.
Wallet A could accept zpub and know the desired path and script type while wallet B may accept the same zpub, ignore its version byte and use the default derivation path and a completely different script type while wallet C could simply reject the string because of "unexpected" starting character (z).
With that said most of the times wallets perform similarly as long as there is a BIP somewhere defining the algorithms.


How to move the blockchain data while still being able to use the wallet?

This step-by-step how-to assumes you are using Windows 7 and installed Bitcoin-Qt to the default directory.

Make sure Bitcoin-Qt is not running
Create a desktop shortcut
Right click on the shortcut
Select Properties
In the "target" box, add -datadir="the new data directory"
Move everything in C:/Users/"your user name"/AppData/Roaming/Bitcoin/ to your new data directory.
Start Bitcoin-Qt with your new shortcut.


Signature on Bitcoin. What am I doing wrong?

The signature is actually correct. However something may be going on with the tool, either you are introducing the parameters in an unexpected format or the tool is not properly working (I haven't been able to verify the signature using the tool either).

Here you have some simple code that uses VButerin's Bitcoin tools python library and verifies that the signature is correct:

from bitcoin import ecdsa_tx_verify

unsigned_tx = "0100000001eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2010000001976a914010966776006953d5567439e5e39f86a0d273bee88acffffffff01605af405000000001976a914097072524438d003d23a2f23edb65aae1bb3e46988ac00000000"
sig = "30460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc0601"  # WITH SIG_FLAG
pk = "0450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6"
sig_flag = 1  #SIGHASH_ALL

print ecdsa_tx_verify(unsigned_tx, sig, pk, sig_flag)

That outputs:

True

Notice that unsigned_tx has been built using all the field from Step 13 but the very last one, that corresponds to the hashtype (4 bytes, 01000000). sig corresponds to the signature adding the hashtype (1 byte, 01), and the pk (public key) corresponds to the one given in Step 15.


clightning uses all my resources, ... till I have to shutdown!

This is most likely the gossipd bug that was causing a request from a peer to be processed very slowly. It was fixed in PR 2268. You don't have that fix in your installation yet, which can be seen by the 5 daemons that are not being reaped correctly (the <defunct> processes in the list). This was also fixed in PR 2224.

Both fixes are not yet part of a release, but we will release them soon.


"Augur" vs. "Oraclize" : What is the main difference?

Full disclosure: Am an Oraclize employee, but also an Augur fan plus REP holder and so am striving for impartiality.

And so to the question: Not really, no.

Oraclize is a really cool oracle service: They are essentially a data transport layer who provide authenticity proofs that the requested data was retrieved and/or computed in exactly the manner the requester of the data asked for.

They don't guarantee the veracity of the data itself, only that it was retrieved/computed in exactly the manner the requester asked for, via third party proofs. And it is these that make Oraclize trustless - you don't need to trust Oraclize, only the provider of the requested proof type.

Better still, this third party nature also allows a requester to appraise the data they are requesting. If choosing say a TLSNotary proof, you're actually relying on an AWS instance, giving you a sense of how much it would cost an attacker to hack such a thing, and allowing you to judge whether your smart contract needs a higher fiscal guarantee or not. And if then you do need a higher guarantee, multiple proof types can be requested, further increasing the cost for an attacker to gain access to/alter the data you're requesting.

And so now to Augur, which is a really cool prediction market. Here, financial incentives drive the accurate reporting of external data by its users. So Augur are a data source themselves, and are decentralized to the tune of however much is at stake, monetarily, on a piece of data being correct. One draw back is the cost of creating such a market, and another is then the risk of that market not generating much traffic, reducing the likelihood of receiving said data as well as potentially reducing the guarantee of accuracy of said data. These risks are inherent to the model and are difficult to assuage. Nevertheless, Augur is a fascinating prospect.

Incidentally, these two different modus operandi can in fact work synergistically - Oraclize can be used to retrieve results from an Augur prediction market, or Augur can use Oraclize to resolve a market - how's that for meta!


Why the amount of listunspent and getbalance is not the same when each data is called by API?

Because Bitcoin Core does not support "balance of address".

The wallet has a single balance, and addresses are treated as separate input gates into that balance, so you can distinguish what is being paid for (by allowing you to give a different address to each payer).

The argument to getbalance is an account name. Accounts are just bean counters: they don't correspond to actual coins in the network. You can change their balance using the move RPC command, which does not even create a transaction. They're a purely local abstraction. You can associate an address with an account so that receives on that address credit the account, and you can use the sendfrom RPC to deduct the sent funds from a given account (but the actual transaction outputs used are still drawn from a pool shared by the whole wallet).

Accounts are a confusing feature however, and they're hard to use in a correct way. That's why they're also scheduled for deprecation in Bitcoin Core.

Perhaps you're looking for the getreceivedbyaddress RPC?


What happens when more transactions are created than confirmed?

If 6 blocks are mined in every hour then in an hour only 12000 transactions will be confirmed. But it seems in every second 3-10 transactions are added. So in an hour, approximate 21600 new transactions will be created.

That sounds approximately correct. Space for blocks is a free market, with a limited amount of supply. By definition that means that not every issued transaction will find a place. This is expected.

Also note that there is no minimum cost or maximum demand for transactions. A transaction chooses its own fee, and anyone in the world could just try to issue large amounts of very cheap transactions if there was excess space in blocks - requiring the whole world to validate them.

  I am surprised that there are 220k unconfirmed transactions in the blockchain. And more transactions are getting queued in every minute.

There are zero unconfirmed transactions in the blockchain. The blockchain contains by definition only confirmed transactions. I assume you're looking at some website that shows you their list of unconfirmed transactions. But there is no guaranteed consistency across nodes. In particular, most nodes on the network use a mempool of limited size, which evicts the lowest fee transactions if it grows too large. On top of that, every node can choose their own policies for what unconfirmed transactions to accept.

The point here is that these is not so much a "queue" of waiting transactions. There is a market of offered transactions, and miners will pick some from them, in some order.

  So what will happen to the unconfirmed transactions, if they lose that money or the transaction will be canceled?

The transactions are not in the blockchain, which means there is no consistency across the network about them, by definition. They may confirm at some point, or not. But as long as they don't confirm, they didn't happen. There is nothing to cancel, or to refund. From the point of view of the network, the transaction just hasn't gone through.

The question is what your wallet software or service will let you do.
It may permit you to treat the transaction as abandoned, and allow you to respend the same money. Look for RBF (BIP125) if you want some technical details, but in short, it's a procedure that permits wallets to replace an outstanding transaction with another one that pays a higher fee.

  See one transaction (Transaction Details) made by one of my friends but not confirmed. So he is thinking to way out from bitcoin. I am so sad that no one will accept this currency if this cannot be solved.

Bitcoin is inherently not a very convenient payment mechanism. It doesn't offer instant payments, or customer protection, or guarantees you're sending to a legitimate business.

All of these things are being worked on as systems to build into or on top of Bitcoin, but there is a lot of missing technology.

  Update: Please consider that I am new to Bitcoin, I just want to know what will happen to the transactions if it is expired?. Also if there is an address change in the transaction then to which address the refund will go (if it happen)

Expiration is just one policy that some nodes choose to determine which transactions to keep in their memory pool. It's not very related to this issue, as anyone on the network could just re-broadcast an older transaction, and it can get accepted again by nodes after it was expired before.


What could stop bitcoin-seeder from "hearing" DNS queries?

The problem stems from the way Ubuntu 18 handles DNS resolution.

My clue was comparing the output of netstat -an | grep "LISTEN " on a machine with a working dnsseed vs the Ubuntu 18 machine with a non-responding dnsseed

The Ubuntu 18 machine showed

 tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN

(which the other did not). Finding this line rather odd, a search for "DNS 127.0.0.53:53" revealed that Ubuntu 18 is handling DNS resolution requests in a particular way (which I have not deciphered), but I found a work-around, which proves dnsseed is not at issue.

dnsseed will answer on Ubuntu 18 on non-standard DNS ports (other than port 53), so the workaround is to use iptables' network address translation feature (NAT) to intercept incoming DNS queries on port 53 and translate them to some other port (using port 5353 in this example) where dnsseed will "see" them.

    dnsseed   -h shido.bitmark.one   -n 139.162.122.138   -p 5353       -m marker@bitmark.io
    srcPort=53
    dstPort=5353
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport $srcPort -j REDIRECT --to-port $dstPort
    iptables -t nat -A PREROUTING -i eth0 -p udp --dport $srcPort -j REDIRECT --to-port $dstPort


How should I integrate Bitcoin payments in an online service?

Survey order:

You ought to have a system that uniquely identifies the survey and assigned it some string of characters. This can be just a simple number, or something more complex.
You need to use that unique id to request a Bitcoin address form bitcoind with a unique account name derived from that id. I would also advise hashing the account name, so in case your wallet gets compromised your customers' information won't get leaked.
You will present that Bitcoin address to the survey owner to send their Bitcoins to.
You should periodically check bitcoind for new transactions. In order to avoid double-spends, you should wait until you get at least 1 confirmation (preferably 6) on the transaction before letting the survey go live.

Survey is live:

You need to have a system that uniquely identifies the users filling out the survey, so they won't do the same survey twice.
Each user will need to provide their withdraw address (and you should check whether it is okay)
You should track who fills out a particular survey and keep a log of their addresses. This way you would be able to make a single payment to all of them at the end of the day, rather than make an individual payment to each person. This would save you money on transaction fees.
You can either make payments from the account unique to the survey, or move all the money into a single payout account and send payments from there. The latter would make the user receive only one payment, rather than be spammed with many. And again, this would lower your transaction fees.
You need to keep track of how much money is left for each survey and when to switch it off. You can either do that internally, or through appropriate balances in bitcoind (moving money from the account each time someone completes the survey).

These should be the basics. As always, keep your wallet secure, password protected and backed up. In case you have any more questions, you can always ask them on this StackExchange. If you need consulting, you can contact me (ThePiachu-gmail-com).


What contributes more to bitcoin network? Using Bitcoin-Qt or running a miner?

What do you mean contribute to Bitcoin? What is your goal?

If the goal is to help with the propagation of nodes, then setting up a bitcoin-qt on a server is nice for the infrastructure and probably the best for a long-term, good guy greg operation. Become a trusted node, add to the infrastructure.

Coins are mined at a steady pace. There's no threat of them being disrupted or mining operations to discontinue. If anything there's a growing number of miners and the difficulty rate is adjusting to match that.

The best thing you can do for Bitcoin is to continue to use it (marketing), or apply one of your skills to its community (entrepreneurial, development, marketing, design, or other). Make a cool Bitcoin t-shirt (and sell them), buy something using Bitcoin, sell something using Bitcoin. When you encounter something difficult in your use of Bitcoin, make suggestions on how it could be improved. People will listen. Your opinion is valuable and matters.


IoT to Hyperledger Fabric, and Tracing / Certifying data

I can certify that the ledger has not been altered by the administrator of my company, but how can I certify that my admin has not altered code listed on those 3 points ?
If I can't guaranty that code has not been altered, how should I certify my data ?

You can’t, and this is the problem with ‘supply chain tracking’ and other such ‘blockchain’ scams.
A blockchain cannot trustlessly certify data from the real world. A user would need to trust that the sensors (or some other oracle) have truthfully uploaded data to the chain.
After all, what is to stop someone from uploading false data? You could only allow ‘certified sensors’ to upload data, but now everyone needs to wholly trust the manufacturers of those sensors. Obviously this is an issue, since the goal of ‘supply chain tracking’ is to apparently reduce potential for abuse / provide more reliable data.
And so in the case where we need to trust some authority to upload truthful data, why not just let that authority provide us with a ~centralized database of that data? This would be an immense cost savings, considering how slow and expensive a blockchain is to run.


Can a malicious majority miner rewrite history?

Let's assume for a minute that your theory is true, and that actual nodes on the network would not accept this new, valid, and longer block chain.

That on itself would be a bug. Maybe it isn't obvious for a 5-block reorganization, but if it was a 2-block deep one (which actually occurs in practice), your argument would be equally true. If there was no means to accept a 2-block deep reorganization, nodes would be stuck in their shorter chain. This is actually exploitable too: someone may intentionally try to get you in such a state, as you will not see new payments on the chain that might conflict with a payment the attacker is trying to send you.

This is true for any depth of reorganization. If we don't accept 12-block deep reorganization, the network would remain in a very sore state if there would ever be a few-hour partitioning of the network. Being able to accept the longest valid chain under every condition is absolutely required for making Bitcoin converge.

So: we need a mechanism to reorganize pretty much any depth. How it is accomplished changed in Bitcoin Core 0.10 with the introduction of headers-first synchronization.

Before 0.10, the attacker would broadcast B11' first, which the victim doesn't know about. It will do a getblocks message to request the hashes of blocks between B5 (using a block locator) and B11'. When it receives these hashes, it will download them one by one using getdata, see they have a missing parent, place them in the orphan pool (the set of blocks without known parent), and when they're all received, notice that they connect, and switch to it.

Since 0.10, the attacker would inv B11'. The victim will use a getheaders message to request the block headers between B5 and B11' and getdata for the block B11' itself. When the headers arrive, they are validated on the fly (in order of increasing height, so they always connect). By the time B11' arrives, we already know about its parents, and know that (assuming the parents are valid) this will in fact be the new best chain. We will then start fetching the actual blocks B6' through B10' to fill in the gaps, and when they have all arrived, switch over to that chain.


I was getting 7 mhash/s on GUIminer.. but only 0.3 on bit minter?

As far as I can tell GUIMiner may have been failing,

The reason why Bitminter says "Warning" is because CPUs are not effective for mining. (I have an Phenom II X6 @ 3.6 Ghz and get the same as you), My graphics card (ATI 7770) can only just mine them now.

How many cores is bitminter set to use?

My recommendation could be for you to mine litecoins and then exchange them for bitcoins. Litecoins mine better on the CPU.


Detecting unconfirmed double spends using bitcoind

bitcoind has a debugging option named mempoolrej. You can enable this by adding

debug=mempoolrej

to your bitcoin.conf file.

This debugging options tells bitcoind to print out information about the transactions that it rejects from the mempool, including why. You can thus enable this option and tail and grep the debug.log file looking for the string

was not accepted

This string is only found in the mempoolrej message which is of the form

<txid> from peer=<peer id> was not accepted: <reason>

The reason you are looking for is txn-mempool-conflict. So you can tail and grep for the entire string:

was not accepted: txn-mempool-conflict

Then with some bash-fu you can make this notify you whenever this string is found in the debug.log file.


How big is the Dogecoin blockchain as of 2018 Feb?

You can follow that and other data on https://bitinfocharts.com/dogecoin/


Installing bitcoind as a dependency on travis-ci

Ubuntu Precise is no longer supported by the Bitcoin PPA team, as the listing showed the .deb package contains no binary. The package description says:

  Bitcoin dummy package - please upgrade to a newer distro for an
  up-to-date Bitcoin package.

  Due to change in Bitcoin Core 0.13.0, we can no longer reasonably ship
  Bitcoin Core for Ubuntu 12.04 LTS. You can either upgrade Ubuntu or
  download the statically-linked Bitcoin Core binaries from bitcoin.org

On the PPA mirror you can see that Trusty (14.04 LTS), Xenial (16.04 LTS), Yakkety (16.10) and Zesty (17.04) are all supported (they have reasonable file sizes). I'd recommend going with Xenial as that has LTS (Long Term Support).

The other option - as the description says - is downloading the binary from the official bitcoin site, unzipping it and using that instead. For the current version:

wget https://bitcoin.org/bin/bitcoin-core-0.14.2/bitcoin-0.14.2-x86_64-linux-gnu.tar.gz
cat bitcoin-0.14.2-x86_64-linux-gnu.tar.gz| gzip -d | tar -xv
./bitcoin-0.14.2/bin/bitcoind


Does Ripple use an RDBMS? If so, which one?

The ripple server uses SQLite for structured data and a configurable "back end" for unstructured "bulk" storage.

The structured data consists of things like transactions indexed by which accounts they affected. The unstructured data consists of "chunks" of data indexed by hash that constitute portions of network history.

The preferred back end for bulk storage is currently RocksDB on Linux platforms.


Procedure to restore Bitcoin Core backup

If you are using bitcoin 0.15.1, it will be using a HD (hierarchical deterministic) wallet by default. This means that all addresses it uses are generated from a single master key in a deterministic way. That means that even addresses you generate after the backup will still be recoverable, as will any transactions sent to them. The exception would be if you upgraded to a new wallet version which supported address types that 0.15.1 didn't (at some point in the future), in which case if you send funds to those address types 0.15.1 might not recognize them (although the private keys can probably still be recovered from your HD wallet


Can individual private keys in Bitcoin Core compromise any part of the HD wallet?

My question is does the default Bitcoin Core implementation (HD wallet) always generate hardened keys in all cases?

HD wallets of the default wallet type, known as the legacy wallet, always uses hardened derivation. It cannot be changed to use unhardened derivation nor can it be changed to use other derivation paths. So it will always be hardened. There are no known issues with hardened derivation. Even knowing child private keys cannot result in learning a parent private key.

Say I want a legacy address and run 'getnewaddress "test" "legacy"' at the console -- will it be HD generated and will it always be hardened? Is there a way to check?

If the wallet is a legacy wallet and is set to use HD, then use, it will always use hardened derivation. You can check this by using getaddressinfo to get the derivation path used. To verify the derivation path, you can use dumpwallet to get the master private key and do the derivation yourself.

If the private key of that specific generated address was later compromised, can anything be leaked about the Bitcoin Core HD wallet from which it came? Is each private key as independent as keys in a "loose keys" wallet? (as mentioned in the article)

Hardened derivation means that it is not possible to learn anything about parent or sibling private keys given a child private key. It is, for all intents and purposes, the same as a set of randomly generated private keys.
However Bitcoin Core now supports BIPs 44, 49, and 84 which specify a set of standard derivation paths which happen to use unhardened derivation. There are used in the experimental descriptor wallets added to introduced in Bitcoin Core 0.21. Unhardened derivation has an issue where it is possible to learn the parent private key if the parent public key and a child private key is known. This can result in the compromise of an entire wallet. It is because of this that descriptor wallets do not support exporting individual private keys, and currently does not have any form of export at all.


What happens to a p2pool payment with an invalid bitcoin address as the username?

If it's actually an invalid address (that is to say it won't hash) such as Address50 then vanilla p2pool will default to sending you (the node) all of the rewards for that miner.

If the address is valid (will hash) but no one holds the corresponding private keys for said address, like 1BitcoinEaterAddressDontSendf59kuE, then the rewards will sit in limbo for all eternity.