What is the minRelayTxFee? What is the minRelayTxFee?
What is it used for, what's the default value and how does the value change?

The minRelayTxFee specifies a feerate acting as a lower bound for a node's mempool. A node will not admit unconfirmed transactions below that feerate to its mempool and thus will not relay them to its peers. The minRelayTxFee is a configuration setting and can be specified by each node operator independently. The value only impacts unconfirmed transactions, transactions included in a block are processed even when they do not meet the minRelayTxFee. Note that contrary to its name's implication, the minRelayTxFee is not an absolute fee, but a feerate.
The current default value for the minRelayTxFee in Bitcoin Core is 1000 satoshi/kB (= 1 sat/B). A node operator may specify a different value via the startup parameter -minrelaytxfee=<amt> or the configuration parameter minrelaytxfee=<amt> which takes an <amt> in [BTC/kB].
The minRelayTxFee also serves as the basis to calculate the minimum cost increments for replacement transactions per BIP-125 (Opt-in RBF). It was also previously used to calculate the dust limit which has since been decoupled into a separate feerate called DUST_RELAY_TX_FEE with a default value of 3000 sat/kvB (H/T Darius).
minRelayTxFee should not be confused with:

minTxFee, which is a wallet configuration setting that sets a lower bound when creating new transactions
mempoolminfee, which is an independent lower bound for mempool acceptance that dynamically increases when the mempool limit is exceeded

Bitcoin Core 0.13.0 introduced a new, optional feefilter P2P message, which will tell neighboring nodes not to send transactions below the filter's feerate. Older nodes do not communicate their minimum feerate, but rather just drop incoming transactions that doesn't pass it.
You may retrieve the current values for your node by calling the getmempoolinfo RPC.


What block space savings would we get for coinjoins (and payjoins) if we had cross input signature aggregation? What block space savings (specific numbers in weight units or vbytes) would we achieve for coinjoins (and payjoins) if we had cross input signature aggregation (post a speculative future soft fork that enabled it)?
This question was asked by Mario Gibney on Twitter and has been paraphrased.

Cross-input signature aggregation (CISA) refers to an idea to produce one shared signature that covers multiple inputs in one transaction. The aggregation is made possible by the linearity of the Schnorr signature algorithm. Note that CISA seems to be mostly interesting for key path spending and this answer will not look at script path spending at all. Further, CISA is a feature in the idea/draft stage and a potential implementation could significantly differ from my current understanding.
Assuming that Taproot activates as it currently is proposed, signature aggregation (for key path spends) would likely require a new output type. Let's assume that Taproot activates as currently proposed and the new output type that supports signature aggregation is otherwise equivalent to Pay to Taproot (P2TR) in all regards.
In P2TR, signatures are part of the witness section of the transaction, and thus they are subject to the witness discount. As proposed by BIP340, Schnorr signatures are 65 bytes (32 bytes for the r value, 32 bytes for the s values, 1 byte for the sighash value). Each input covered by the aggregated signature would see its signature replaced by a one byte placeholder, except for the last input whose witness would contain the aggregated signature. Given a transaction with n aggregated inputs, the savings would be (n-1)×64 WU (weightunit) assuming no additional overhead is necessary for the cross-input signature.
In a P2TR transaction, a key path input weighs 230 WU (57.5 vB), the transaction header weighs 42 WU (10.5 vB), and a P2TR output is 172 WU (43 vB).
Let's assume that a coinjoin transaction is created by multiple participants where each participant contributes two inputs, one recipient output, and one change output. If each user performed this transaction separately without CISA, each user would incur a transaction weight of:
42 WU + 2×230 WU + 2×172 WU = 846 WU.
With CISA, the cost for a single participant just aggregating the signatures of their two inputs, this cost would reduce to:
42 WU + 2×230 WU - 64 WU + 2×172 WU = 782 WU.
When two participants throw in together, the cost per participant would go down to:
(42 WU + 4×230 WU - 3×64 WU + 4×172 WU) / 2 = 1458 WU / 2 = 729 WU.
For five participants the cost per user would become:
(42 WU + 10×230 WU - 9×64 WU + 10×172 WU) / 5 = 3486 WU / 5 = 697.2 WU
For ten participants, the cost per user is:
(42 WU + 20×230 WU - 19×64 WU + 20×172 WU) / 10 = 6866 WU / 10 = 686.6 WU
As you can see, the cost per user decreases with the number of inputs/participants, and thus there is an economic incentive for multiple users to create a transaction together. However, the savings are limited in that they asymptotically approach 64 WU per input as the input count increases. The greatest savings are achieved by the first two participants joining up, with each additional user bringing diminishing returns. If a user already has a lot of inputs by themselves, coinjoining provides them only with marginal savings since the savings by joining with others are fixed to splitting the header and last remaining signature by the number of participants.


How wallets/ miners differentiate bitcoin and bitcoin cash (forks of cryptos)? (technical IT question) I could not find the answer by web search. People usually interested in economic differences. I guess it is a question for those who know how mining algorithms works.
Internet is kind of decentralized. But there is single domain servers grid that tells where to find google.com. In a world of cryptos, how do wallets know where to send your BTC / BTC cash transaction? How to differentiate between forks? Is there some list of agreed gateways like for TOR? If so who administers it?

The protocol administers it.
Usually, one coin's blockchain will not be compatible with another's: for example, Bitcoin supports Segwit transactions, and Bitcoin Cash does not; whereas Bitcoin Cash has a high block size limit and Bitcoin does not. The point at which the two diverged is the point at which Bitcoin started mining Segwit blocks (which Bitcoin Cash clients will not accept as valid blocks, because they contain Segwit transactions), and where Bitcoin Cash started mining large blocks (which Bitcoin clients will not accept as valid). However, if there was a transaction that was valid on both blockchains (as may have been the case around the time of the fork), then that transaction can indeed be "replayed" on both blockchains, with both accepting the transaction.


How to increment the number of confirmation of a transaction? Sorry for this naive question, but honestly it is going to be a great help for me.
Say I am tracking a specific bitcoin transaction('TX_1') form bitcoin core. A confirmed block had the transaction information after I decoded the block, and I updated my database as :  {transaction: 'TX_1', 'confirmation': 1}
now how do I increment the number of confirmation, assuming I am still listening to the network through ZMQ. Should I expect the same transaction ('TX_1') to be present in upcoming blocks?

A tx will only be included in a single block in any given blockchain.

Confirmations is simply a count of how many new blocks extend the chain.

If your tx is in block n, it has 1 confirmation. When block n+1 is mined, you need to check that the prevblockhash is the hash of block n. If it is, you now have 2 confirmations, since the chain has been mined. When block n+2 is mined, you check the prevblockhash against the hash of block n+1. If this is valid, you now have 3 confirmations, since block n+1 builds upon the block with your tx, and block n+2 builds upon block n+1. You can keep checking this for as many blocks as you feel necessary to guarantee that your tx will not be dropped. Most wallets/exchanges check until a tx has 6 confirmations.


does bcoin support simplified payment verification (SPV)? Does bcoin support simplified payment verification (SPV)? I can't seem to find anything about it online

Yes, it supports SPV out of the box. Bcoin actually started out as an SPV project according to Buck Perley.

Here is an example on how to start up a bcoin node in spv

https://github.com/bcoin-org/bcoin/blob/master/docs/Examples/spv-sync-wallet.js


Address reuse for business The consensus is that address reuse is bad and should not be done. Bitcoin wiki even argues it hurts yourself and those who will own the bitcoins after you.

However, unless I am mistaken, most business reuse the same address all the time. They have to, to avoid having to generate a new address every time someone visits their website.

So I am struggling to reconcile this. Is address reuse actually ok? Am I wrong in saying that business reuse addresses? Or are most businesses creating a privacy issue in the block chain?

This is more an issue of willingness.
Generally you are right, address re-use is seen as "should not be done" :-)
Biggest threat would be, that some bitcoins get "tainted", and loose their value. I leave it to the experts to get this explained.
With HD Wallets you can generate enough adresses for your webpage/business usage. Just some coding required...

How many public/private keypairs can a Hierarchical Deterministic Wallets (BIP0032/BIP0044) produce? If I got it right, it should be some 2^31 addresses - probably enough for the majority of business cases.


Will skipping nonce enchance mining performance given there's more resourceful miner As most miner program start with 0 nonce and increment from there, given there are many resourceful miners who will also compete for the same desirable nonce:

Everyone is mining at [0 ~ LARGE_RANGE] (lower range)

I mine at [LARGE_RANGE + 1 ~ MAX_RANGE] (upper range)

Scenario 1: Other people found the desirable nonce at the lower range, they do it way quicker than I do even if I were to mine on the same range.

Scenario 2: The desirable nonce is at my range and I found it first(before others found it since I skipped the lower range)

Is this a possible way to improve my mining performance?

The blocks you try to mine will have your block reward address in them. The blocks other people try to mine will have their reward address in them. Because the blocks are different, any correct nonces will also be different.

When you mine, you are not competing with other miners in the same search space. Whoever finds their own nonce first wins, but everybody is looking for a different nonce.


Practical tips for validating raw transactions I have a protocol that creates a raw signed transaction that is then broadcast to the network. The transaction aims to send X BTC to a single address Z. The transaction is created with the help of bitcoin core.
In the past I've seen a few instances where people got themselves in trouble by creating unexpected transactions, for example by paying 90% of the UTXO's value as a mining fee or the like.
Therefore I was wondering if someone could advise on procedures/tips for the following

Given a raw transaction T sending X BTC to address Z, how to validate the transaction accomplishes this gracefully?

The idea is that before the broadcast one issues an additional decoderawtransaction and checks that everything is as intended. I would like to hear tips on what one should check for at this point.
I understand the question itself is a bit vague but I'd like to hear any kind of feedback on what to look for in the output of decoderawtransaction that might be telling something is either not right, or validate that

The transaction is sending X BTC to Z,
What the exact expenditure (X+fees) is,
That the change is sent to the right (i.e under the wallet's control) address.

A very useful RPC is the testmempoolaccept RPC. This will tell you whether the transaction would be accepted by the node. You can use this to determine whether the transaction is correctly signed. It will also tell you what the transaction fee is so you can determine whether the fee is what you expect it to be. If the transaction would not be accepted, it will also tell you what went wrong.
To ensure that the transaction is logically correct (i.e. money is being sent to the right place), you can use decoderawtransaction and examine the contents of the vout array. Each output is in that array and the value for the output and the address, if any, will be listed. So you can scan that array and make sure that the intended recipients are there with the correct values.
It is harder to determine change, but if you know what the change address is and what the change value should be, then you can check it as if it were another recipient as described earlier.

One caveat about testmempoolaccept: it only works if the parent transactions are confirmed or in the mempool. The test it runs is on the mempool state at the time of the call, so it behaves as if you had done sendrawtransaction at that moment, except the part where the transaction is actually sent and added to the mempool.


Why do we inverse the hash of the blockheader? Let's pick this example blockheader-hashing in Python:

from hashlib import sha256
import hashlib
header = "0000002066720b99e07d284bd4fe67ff8c49a5db1dd8514fcdab610000000000000000007829844f4c3a41a537b3131ca992643eaa9d093b2383e4cdc060ad7dc548118751eb505ac1910018de19b302".decode('hex')
print sha256(sha256(header).digest()).digest()[::-1].encode('hex')
// result is 00000000000000000020cf2bdc6563fb25c424af588d5fb7223461e72715e4a9

I know that it's part of the protocol and otherwise, a block will not be accepted, but:

Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?
But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

So what's the reason of inversing it?

Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?

Counting the number of leading or trailing zeroes does not give a lot of granularity. If represented as a hex number, then there are only 64 possible target values if you are counting just the number of zeroes. If in binary, that is 256 possible values. Furthermore, counting the number of zeroes means that you can only change the difficulty by some power of 2 (in binary, the difficulty has to be doubled or halved). There are thus not many values for the target and this loss of granularity is bad.

Conversely, comparing the value means that there are (in theory) 2^256 possible values for the difficulty. This is much more granular, and these values are integers. Instead of having to change the difficulty by multiplying, the difficulty can be changed with addition and subtraction. By having more values, the difficulty will be less likely to be too hard or too easy.

  But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

It is actually just like you said. The reversing of the hash is only for how the bytes are actually represented. They are stored as bytes and interpreted as a little endian 256 bit integer. The comparison is still an integer comparison and the data representation is irrelevant (they could just as easily be stored and represented as big endian integers). But when they are displayed, they are displayed as big endian values in hexadecimal because humans are accustomed to big endian. The reason for little endian is likely because the x86 architecture uses little endian for storing integers.


Is my ECDSA signature always unique? In P2PKH the validation script is:
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

If I always use exactly the same private key and always sign exactly the same message with it, is my <sig> unique among all my transactions?
Furthermore, if <sig> was always the same for all my transactions, would that mean that everyone who knows my <sig> can impersonate me?

Digital signatures really aren't much alike someone's John Hancock. Digital signatures cryptographically commit to exactly one message and resolve as invalid for any other messages. Unlike someone's three crosses they cannot be lifted from one document to another or easily imitated.
ECDSA's signature algorithm uses two inputs, the private key and the message that the signature commits to. In the case of Bitcoin, the "message" is the Bitcoin transaction you mean to commit to.
The signature is mathematically derived from the message, the private key, and a random component generated during the signing. While producing the signature requires knowledge of the private key, the signature can be validated by anyone who knows the message, the signature, and the corresponding public key. The signature will only ever fit that specific transaction. Any other transaction would require a signature to commit to a different "message", and such a signature could not be produced without knowledge of the private key.
As a transactions spends at least one unspent transaction output (UTXO), and each UTXO is unique¹, the premise of "signing the same message" is in conflict with "same for all my transactions". As each transaction must be unique, signatures do not transfer, even if the transaction spends inputs associated with the same private key. Therefore, yes, every signature is unique.

Furthermore, if <sig> was always the same for all my transactions, would that mean that everyone who knows my <sig> can impersonate me?

No, that's not how signatures work. If your signature was always the same for all transactions, they would not be useful. Such a "signature" would not prove that you committed to something specific and therefore could not be a means of authorizing a payment.

¹ A UTXO are uniquely identifiable by their outpoint which consists of the txid that created it and the output's position in that transaction's output list. txid are the SHA256D digest of the transaction data. This is defacto unique since BIP34 requires Coinbase transactions to include the block height, which therefore by induction means that no transaction can ever consist of the same data.


Would this scheme allow faster verification of transactions? (Multiple parallel block chains) One issue with one block chain is that it needs to be globally synchronized. One way to elevate this would be to use multiblock chains.

Namely, we can imagine that there are N block chains, working in parallel. To make double spending impossible, a you can only spend a total of 1/N of your total money on each chain. (If they need to spend more, you can do so on multiple chains. This is slower, but hopefully you don't need to do that as often. If, for example, there 10 chains, you have 100 units, and you are buying something for 15 units, you would spend 10 on one chain and 5 on another.)

After about 10 blocks or so (specifically when it happens is unspecified for now), a meta-block is mined that ties the chains together. This resets the 1/N limit, and allows money earned on one block to spent on the others. Otherwise, it would just be N different currencies.

Each individual block chain can go faster, since they will involve only 1/N of the community. More total blocks also means miners are rewarded more often, and more spread out.

Would this work? Would it verify transactions more often? Do any currencies currently use this?

I'm not sure this is the right forum for this sort of discussion, but I'm not a mod.

Anyways, decreasing the transactions in a chain does nothing to make block creation faster.  That is a hard-coded target in the code.  If the hashing power goes down, the difficulty goes down, and it all balances back at 10 minutes.  There's no benefit in terms of confirmation speed from your proposal.

Total hashing power is also a big factor of overall security.  With your proposal, instead of 1 chain with with hashing power of X, you have N chains each with hashing power of X/N.  It means that the cost to attack a single chain with a 51% attack decreases by a factor of N.  That's not good.

This also does nothing to solve the problem of centralization of mining power.  Big mining pools will simply diversify their hashing power across all N chains, giving them the same proportional control they currently have.  No benefit there.

Given the complexity that will be required to re-sync the chains, and not really getting any benefit from it, I would say that this idea would not work.

I think you may be interested in a similar concept called sidechains.  You should give that a read, since it might be what you are after.  If you are more interested in instant transactions, I think you would find the Lightning Network interesting.


How long does it take to update all nodes that have the blockchain so that they are identical? Beginner questions...

I understand that everybody has their own copy of the blockchain.

If one person makes a change, for example a transaction, I assume that it has to propagate to all other nodes. How long does this take?

How does a node know that the update process is complete throughout the blockchain?

What algorithm is used to synchronize and what is its order (O())?

The Blockchain is never changed only extended.

As I understand it, nodes do not explicitly check or care whether other nodes have identical copies. They just verify what they receive against what they already have in their copy of the Blockchain.

Synchronisation isn't exactly the right word to describe what happens but it effectively occurs as a consequence of nodes applying the same "consensus" rules. Nodes follow the longest chain, the one with most proof of work.


Checksum vs. Hash: Differences and Similarities ? What are similarities and differences between a "checksum" algorithm and a "hash" function?

Can they be used instead of each other? Or their usage are different?

For example, for verifying the integrity of a text, which one is better to be used?

Sometimes these terms are used more or less interchangeably.  Traditionally, a checksum is used to detect corruption and a hash is used to map large elements into slots randomly.  In Bitcoin-land we're often concerned with "cryptographic hashes"  which are hashes that have special security properties.

Things called checksums are usually designed to have certain uniformity properties that make them maximally likely to detect errors.  Things called hashes are usually designed to be very fast to compute and not be too non-uniform.  Things called cryptographic hashes are designed to make it difficult to compute a collision.

The security properties of cryptographic hashes often make them slower and less uniform than functions you would use for cases where the security isn't required.

Generally any function from any of the three groups could be used in any of the applications, the result would just not achieve the security, performance, or reliability that you'd get for using the right tool for the job.


I know my address but can't remember which site it's from I signed up for a bunch of different wallets because I didn't know which one was the best. I have 2.5 bit coins in a wallet that I don't know how to get. I know my wallet address, but can't remember which site it's from. Can someone help me, please?

It isn't trivial to de-anonymize a bitcoin address. Your best hope is that the address has inputs or outputs to other addresses that have been deanonymized somehow (search online for those addresses). This is unlikely though. You would be better just checking all the wallet sites with your login(s). As @nate-eldredge mentions this carry's the risk that you might reveal your login/pass combinations at some exchanges that are not trustworthy.

One tool that seems to have some information about addresses is OXT. For example it determind this address to be associated with btc-e exchange


How can I get the private key from wallet.dat from 2011 Bitcoin software on WinXP? I set up Bitcoin (application) software on a WinXP machine in 2011 and received some Bitcoin. I set the machine aside, disconnected from the internet. Now I want to access the 2011 Bitcoin.

Lately I verified my Bitcoin address/public key on blockchain.info, and the BTC is still there. I backed up the public key and wallet.dat* onto a flash drive. The WinXP machine is functioning.

I am a former coder but new to Bitcoin under the hood, but willing and able to learn whatever is necessary to retrieve, control, and move the BTC. *I suspect that the wallet.dat file "contains" the private key, but I can't read the file contents with Notepad.

What secure tools do I need, and what is the best way to fill my knowledge gaps so that I can resume control of the BTC?

The wallet.dat was created with Bitcoin Core (in 2011 it was called "Bitcoin").

You should install the newest version of Bitcoin-Core (0.14.2 by the time of writing). The wallet.dat from 2011 should still run.

Use the GUI.

If you want to export the private key, you don't need to sync (takes a couple of hours / days)

Can also be done on a different machine then your Windows XP box.

Following steps may help:

Start Bitcoin Core
Stop Bitcoin Core
Datadir should be created, open the datadir folder (https://en.bitcoin.it/wiki/Data_directory)
Replace the existing wallet.dat (backup it if you already had Bitcoin Core installed) with your old wallet
Start Bitcoin Core
If you want to export your keys, open the debug console and type dumpwallet <filename>
If you want to use Bitcoin Core, let it sync (takes a couple of hours/days)


Access to exchanges' (especially Mt. Gox's) transaction history? I'm attempting to do statistical research on the Bitcoin market, and I would like to have access to the transaction data of as many exchanges as possible. Specifically, I'm looking for every trade made on a given exchange. Mt. Gox is obviously my primary interest because it handles the highest volume. Is this data available for download anywhere, or am I going to have to start collecting it myself? Specifically, I want to be able to store all transactions in a SQL database, so I would like them in an easily parsable format.

You can use the API to retrieve such data.


How can i check bulk BTC address balance? I'll appreciate some suggestions for online resources or software that can be used to check/monitor a few thousands of BTC address. Thanks

Easiest way would be to simple import the addresses into Electrum.  It's an SPV (light-weight) wallet with no need for blockchain downloads.

Go to Bitcoin.org and select "choose wallet"
Click Electrum from the list and follow the installation instructions.
When you start Electrum choose to start a new wallet (default, hit next)
Choose "Import Bitcoin Address" then hit next
Hit the folder icon in the bottom of the import window and import the file containing the thousands of addresses.

Since you are only dealing with public addresses you don't need to worry.  To future readers... always be cautious of downloading wallet SW.  It is a primary target for those looking to defraud you.  There are some browser plug-ins that can help and some good common sense.  Just be cautious.


if a Bitcoin mining nounce is just 32 bits long how come is it increasingly difficult to find the winning hash? I'm learning about mining and the first thing that surprised me is that the nounce part of the algorithm which is supposed to be randomly looped until you get a number smaller than the target hash .. is just 32 bits long. Can you explain why then is it so difficult to loop an unsigned int and how come is it increasingly difficult over time? Thank you.

Edit: It's been suggested this is a duplicate, this is not. The other question asked if you could run out of nounces, that's nothing to do with my question. My question is about the difficulty of Hashing the exact same 4 billion unsigned int entry loops.

It is not the looping that is difficult, it is generating a hash for each iteration of that loop.  Furthermore, as @Nate pointed it, a miner will likely have to change more than just the nonce.  As more transactions are coming in from the network, a miner will add/swap them into the block they are hashing, presumably based on maximizing transaction fees.  Each time the transaction set is modified, all tried nonces can be tried again.

As for why it gets more difficult over time, that is a core part of the protocol.  Every 2,016 blocks, the target hash re-adjusts so that blocks will take about 10 minutes.  As more hashing power enters the network, the faster blocks are found, which in turn will trigger the re-adjustment after 2,016 blocks.


Softforks details in a 0.12 full node I have a 0.12 full node syncing in prune node.

This is what I get when I execute getblockchaininfo

pi@raspnode:~ $ bitcoin-cli getblockchaininfo {
    "chain" : "main",
    "blocks" : 276483,
    "headers" : 403136,
    "bestblockhash" : "00000000000000017871bf646ec12c1e2dedacef87dcd357cea0da1ddb0b64b5",
    "difficulty" : 1180923195.25802612,
    "verificationprogress" : 0.11950119,
    "chainwork" : "00000000000000000000000000000000000000000000084f5ed912538557eaa8",
    "pruned" : true,
    "softforks" : [
        {
            "id" : "bip34",
            "version" : 2,
            "enforce" : {
                "status" : true,
                "found" : 1000,
                "required" : 750,
                "window" : 1000
            },
            "reject" : {
                "status" : true,
                "found" : 1000,
                "required" : 950,
                "window" : 1000
            }
        },
        {
            "id" : "bip66",
            "version" : 3,
            "enforce" : {
                "status" : false,
                "found" : 0,
                "required" : 750,
                "window" : 1000
            },
            "reject" : {
                "status" : false,
                "found" : 0,
                "required" : 950,
                "window" : 1000
            }
        },
        {
            "id" : "bip65",
            "version" : 4,
            "enforce" : {
                "status" : false,
                "found" : 0,
                "required" : 750,
                "window" : 1000
            },
            "reject" : {
                "status" : false,
                "found" : 0,
                "required" : 950,
                "window" : 1000
            }
        }
    ],
    "pruneheight" : 0 }

I would like to understand the new specs about softforks. I know id is the BIP id. But what about this block of code?

                "enforce" : {
                    "status" : false,
                    "found" : 0,
                    "required" : 750,
                    "window" : 1000
                },
                "reject" : {
                    "status" : false,
                    "found" : 0,
                    "required" : 950,
                    "window" : 1000
                }

Soft forks are changes in blockchain rules that add restrictions on which blocks are valid. Soft forks require a certain portion of miners to show that they have upgraded their software in the blocks that they mine before the rules go into effect. This is done so that miners stay in sync about which blocks are valid and which blocks are invalid. What you're seeing in that data is basically a progress report of how many miners have upgraded their software to show support for each of the soft forks.

Let's look at BIP34:

    {
    "id" : "bip34",
    "version" : 2,
    "enforce" : {
        "status" : true,
        "found" : 1000,
        "required" : 750,
        "window" : 1000
    },
    "reject" : {
        "status" : true,
        "found" : 1000,
        "required" : 950,
        "window" : 1000
    }
}

This shows that BIP44 applies to all blocks with nVersion number greater than or equal to 2. It becomes enforced (the soft fork rules actually go into effect on blocks with version >= 2) when 750 (required) of the last 1000 (window) blocks have a version greater than or equal to 2. To date, 1000 (found) of the most recent 1000 blocks on the network have signaled support for BIP34 by using a version number greater than or equal to 2 in their block. Thus, since it is over 750, the "status" is true and it is being enforced.

The reject portion shows similar info, but it's describing when the network will no longer accept blocks with version below the BIP34 version. So, when 950 (required) of the last 1000 (window) blocks on the network have nVersion >= 2, blocks with version < 2 will no longer be accepted by the network. Currently, 1000 (found) blocks have had version >= 2, so the reject status is also true, meaning blocks with version < 2 are rejected by the network.


Displayed transactions may not be correct! When I enter bitcoind getinfo on my remote ubuntu-Server I get this answer:

{
    "version" : 32400,
    ... (some other info)
    "errors" : "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
}

What went wrong?
How can I fix it?

This is what I did before:

I am running a remote server with Ubuntu 12.04 LTS as operating system. The machine is 800 km away from my home, I am connected to it via SSH. So there is no GUI, I only can use shell commands.

Yesterday I installed bitcoind calling this shell-command (while beeing root) after upgrading all other packeges (apt-get update followed by apt-get dist-upgrade):

# apt-get install bitcoind

bitcoind and 8 or 10 other packages was installed.
Then I edited /root/.bitcoin/bitcoin.conf and entered this:

  server=1
  daemon=1
  rpcuser=[my username]
  rpcpassword=[very long passphrade]

Then I did start bitcoind by calling

# bitcoind

The answer was

  bitcoin server starting

but even after waiting more then 5 minutes I did not get the shell back (I could not enter new commands). So I pressed

  ctrl-c

When I entered bitcoind again, I found that is already was running:

  Bitcoin: Cannot obtain a lock on data directory /root/.bitcoin.  Bitcoin is probably already running.

It was also running after closing and re-opening the ssh-conection to the server. So I thought everything was ok now. I also generated a bitcoin-address which worked fine.

Now, about 12 or 14 hours later, I reconnected to the ubuntu-server and entered

# bitcoind getinfo

but the answer was

  error: couldn't connect to server

also displaying all active processes by calling top showed me, that bitcoind was not running. So I started it again by entering bitcoindin the command line, but again I didn't get the shell back, so again I had to press ctrl-c. But when I entered bitcoind getinfo after that I got the answer that I posted at the beginning of this posting ("errors" : "WARNING: Displayed transactions may not be correct! ...)

So here are my questions:

What went wrong?
How can I fix it?
How can I start bitcoind and get back to shell again?
How can I stop bitcoind? (I just can kill the process, I don't know any other way)

EDIT 1:

(2014-01-08; evening)

About stopping bitcoind: I found out that the command is bitcoind stop. But when I tried this yesterday I got an error (sorry, can't remember the exact error-message. I guess it sayed "unknown command", but I'm not shure)

EDIT 2:

(2014-01-09; morning)

Yesterday I stopped bitcoind and deleted everything in the directory /root/.bitcoin/ except wallet.dat and bitcoin.conf. Then I started bitcoind again. Even after about 8 hours it still worked fine. Sometimes it took up to about 20 seconds to respond to commands like bitcoind getinfo, but bitcoind always did give the expected answer without any error messages.

So I went to bed and this morning I logged in to my server again and I found that bitcoind was not running (the answer to bitcoind getinfo was error: couldn't connect to server).

So I started it with the command bitcoind. The answer was bitcoin server starting, but I did not get back the shell (I am unable to enter new commands). So I opened a second shell and entered bitcoind getinfo there, and after a few seconds the server responded with an status-json-object with an empty error-string (which means: no error). So I think the start was successful. But the first shell (where I did start bitcoind) is still hang up, since more than 30 minutes now.

You are running bitcoind 0.3.24.  This is a very old version that won't work properly on today's Bitcoin network. The latest version is 0.8.6.

It appears that the Ubuntu maintainers have not updated the version of bitcoind in the standard 12.04 repository; so you'll have to get a current version from somewhere else.  The Ubuntu developers maintain a repository of their own for bitcoin, so you can install the latest version by doing:

sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

You can also get these instructions from an "official" source by going to http://bitcoin.org/en/download and following the "Ubuntu (PPA)" link.

In answer to your other question, when you run bitcoind without arguments, it runs in the foreground and accepts commands on standard input (after a delay of a minute or two while starting).  You can exit it by typing stop.  You can also run it in the background by doing bitcoind -daemon, and then feed it commands by running bitcoind getinfo, etc.


How can hackers cash out stolen bitcoin? I've read about a lot of Bitcoin Heists and Thefts: from hackers that stole bitcoin from Exchange (Due to their poor security measures) or from Bitcoin users, to scam websites and so forth.

Some of these Heists and Thefts involve huge sums of Bitcoin.

So, I was wondering: how can the hackers that had done these Heists/Thefts, be able to "cash out" the stolen bitcoin?

For example, let's say that an hacker has stolen 1000 bitcoin from Bob's wallet, and he wants to sell the bitcoin for USD (With the current exchange rate: 1000 bitcoin = $445.000), so that he will be able to "enjoy" the money in his real life. But how?

1) Obfuscating the transactions:

Thanks to the Blockcahin, everyone will be able to see all the transactions from the address (Or addresses) where the 1000 stolen bitcoin are (So Bob can try to track him down). I guess that the hacker could use a mixing service, but: can he trust the mixing service? (There is the risk that the mixing service is just a scam; or that the mixing service turns into a scam, when the hacker try to launder the 1000 bitcoin and instead of launder the bitcoin, the owner of the Mixing service just steals the hacker's bitcoin). Or probably, he has already created his own "network" of bitcoin addresses, so that he can launder the stolen bitcoin by himself? (but could this be possible to set up? Or it would require too much time and efforts?).

2) Selling the bitcoin:

Then, he has to sell the bitcoin. Where? The vast majority of Bitcoin exchange require ID verification to be able to withdraw from them (Although there are few exchange that allow their clients to have unverified accounts, but they have strict limits such as 5000 USD o 10.0000 USD yearly, for example. And there is still the possibility that the exchange, being suspicious of these transactions, decides to froze the hacker's account.)

Probably he can sell the bitcoin to other people that want to buy bitcoin, on forums and so on; but wouldn't be too risky? Firstly, the hacker will have to find a lot of users that want to buy bitcoin (I don't think that he will find a user that wants to buy 1000 bitcoin on a forum); moreover, there is the risk that the hacker gets scammed by one of the buyer. Lastly, the transactions will be displayed on the blockchain, so Bob can still track him down (if the hacker hadn't used a mixing service or something similar) and try to contact the users that have bought the bitcoin, asking them information about the hacker.

Or probably the whole thing is much easier and hacker can have a bank account or a credit card (Obtained with Fake ID) that is not connected with his real identity? In this way, he could easily sell all the bitcoin that he wants to an exchanger and withdraw all the profits from the sale.

What do you think about?

Interesting points Paper, here some of my thoughts...

As you said, on the underground (i.e. TOR) there are forums where thieves are selling dirty coins, with a favorable exchange rate (1 clean coin for 2 dirty coins for example). But to avoid scam I suppose they will use some kind of anonymous escrow service to perform the exchange, to guarantee that both parties are willing to complete the transaction.

Mixing service are also risky since they only guarantee anonymity if there are actually other user's coins to mix with. I remember some time ago, when a thief sent a huge amount of stolen coins at once to a mixing service, the returning coins were practically the same since on the mixing service there wasn't other users mixing such big amounts.

I don't get the point about "his network of Bitcoin address" what you mean? You can generate thousands of addresses and send coins back and forth, but this will actually just obfuscate (you can always track from start address to destination). The only way to really mix them, is to mix with other user's coins.

Furthermore many stolen coins are probably used to purchase illegal items from hidden markets  (drugs, weapons, pretty much anything). So they are actually "enjoying" them without the need to exchange them in "real" currencies.

And last but not least, in person exchange (for example thorough localbitcoins.com or another local directory for Bitcoin buyer and sellers)

Cheers


Can I safely run Tor and Armory through Tor simultaneously? Would running armory through Tor affect the anonymity of Tor Browser, or vice versa? Are there any unusual precautions I should take when doing this?

No, it's a bad idea to run bitcoin over tor if your striving for anonymity. Here is a paper detailing the vulnerability.

  While Bitcoin provides some level of anonymity (or rather pseudonymity) by encouraging the users to have any number of random-looking Bitcoin addresses, recent research shows that this level of anonymity is rather low. This encourages users to connect to the Bitcoin network through anonymizers like Tor and motivates development of default Tor functionality for popular mobile SPV clients. In this paper we show that combining Tor and Bitcoin creates an attack vector for the deterministic and stealthy man-in-the-middle attacks. A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor. In particular the attacker can link together user's transactions regardless of pseudonyms used, control which Bitcoin blocks and transactions are relayed to the user and can delay or discard user's transactions and blocks. In collusion with a powerful miner double-spending attacks become possible and a totally virtual Bitcoin reality can be created for such set of users.


Will bitcoin's value be affected by other digital currencies? There are many different digital currencies being released now, following in the footsteps of bitcoin and trying to improve upon it.  Will these currencies, by giving consumers more options, reduce demand for bitcoin and decrease or limit the increase in its value?

Stephen's answer made me realize that I'm not just talking about any crypto but the one's that will inevitably improve upon the already great bitcoin model.

Bitcoin is a "proof-of-work" based cryptocurrency.  Proof-of-work based cryptocurrencies are protected from a malicious 51% attack because of that coin's mining network.

Bitcoin is protected by 12,500 Th/s of mining capacity (using SHA hashes).  For an attacker to come in and attempt to commit "double spend" fraud (as the result of having 51% of the mining capacity), that attacker would need to spend perhaps a hundred million dollars to acquire the necessary mining hardware.  There is no way, today, that an attacker will be able to use this tactic to earn a profit because there's simply no way to withdraw even tens of millions of dollars worth of funds from exchanges (following the attack) -- due to exchanges employing KYC/AML policies such that an attempt would fail either due to withdrawal limits, access to cold-storage, etc.

Alt coins don't have this same threshold.

So in addition to Bitcoin having first-mover advantage and the strongest "brand" (thus that's why Overstock accepts Bitcoin and not Litecoin or anything else), it has the least risk of catastrophic loss due to a malicious 51% attack.

The difference between Dogecoin and a Bitcoin is like the difference between investing in a longshot penny stock issue of a nearly bankrupt company versus buying a blue chip NYSE which continues to deliver quarter-after-quarter.

So there is certainly a substitution effect.  Many of those speculating on Litecoin would otherwise have been holding bitcoins.  But there's not an easy way to know what the value of a bitcoin would be if the $500+ million valuation of all Litecoins in circulation were to grow by several billion dollars.  Since we haven't reached "saturation", perhaps many of those speculating on Litecoin might not have held Bitcoin regardless -- and thus if that were the case the existance of Litecoin didn't affect Bitcoin's exchange rate.

There's also the situation where an altcoin happened to be the "gateway drug" that caused a person to become interested in crypto currencies but then that person later embraced Bitcoin. In that instance, the greater the traction of that type of person to an alt currency eventually results in greater traction of Bitcoin.

There's also other altcoins that are not proof-of-work based.   For instance, PPCoin is a "proof-of-stake" crypto currency.  These are not vulnerable to a 51% mining attack (though they have other vulnerabilities).  So it is possible that those PoS coins could be seen as having an equal (or lesser) risk to that of Bitcoin and thus that coin could be seen as a substitute for Bitcoin by some.

To conclude, simply alt coins are not equivalent to bitcoin and thus a dollar spent on acquiring an altcoin doesn't mean there is one dollar less spent on acquiring or holding a bitcoin.


Restricting a wallet to a specific destination address I have an idea for a tool I'd like to build, but first I need to understand the Bitcoin protocol a little better.

Is there any way, hypothetically, to ensure that a given wallet or address can only transmit to a restricted address or set of addresses?

The protocol itself doesn't allow such a restriction but M of N functionality might be a way to implement something like this.

How will multisig addresses work?


Lock BTC amount for a while I am working with the blockchain wallet API and my workflow is something like this: whenever the user wants to buy BTC from me, at that time, whatever the amount is added by the buyer, at that time that particular amount will be locked from his account, and after a while that amount will be released and transferred to another user.

Is there any way to implement this?

You're users are not in control of the private keys, so you do not need to lock them via the Bitcoin protocol. This is just a simple permission feature you should build into your system using a database. If a user "buys from you" then update a field in your database for that user, for example the database field could be called locked and then you would have it changed to true.  Then make sure that you build your system to check this field is false every time prior to withdrawal.


Estimate smart fee returns an error I am trying to get current fee for per transaction. So running command

bitcoin-cli estimatesmartfee 6

i am getting response lookl ike this

{
  "errors": [
    "Insufficient data or no feerate found"
  ],
  "blocks": 1
}

How ca I get real fee?
Thanks!

It appears the node is not fully synced the entire blockchain. If your node is not fully synced, then it hasn't parsed the latest blocks to see what a reasonable tx fee would be for the current market. If it's not fully synced, then it might try to estimate based on old transactions, which you don't want, since they could be much lower (and your tx will never confirm), or much higher (and you overpay in fees).


How much bitcoin do companies have on their balance sheets? How much bitcoin do publicly-traded companies currently have on their balance sheets?  Is the information available online?  If so, where can it be found?

If a public company accepts bitcoin, it would be recorded on it's balance sheet as Cash.  You might be able to discover the amount by getting lists of companies that accept Btc and then looking it up in their annual (10-K) and quarterly (8-Q) reports on EDGAR (https://www.sec.gov/edgar/searchedgar/companysearch.html).


What standard is used for the ECDSA to verify transactions? Bitcoin used Elliptic Curve Digital Signature Algorithm. (see here). I'm wondering what standard is actually used for this Algorithm: which curve? which prime? Can anybody give me a reference? (Wiki gives this, is this the standard that the ECDSA in Bitcoin?) Anywhere I can find an update on this?

Edit: A bunch of curves are given in page 87 of this. Is bitcoin using one of these?

I just found the answer from https://en.bitcoin.it/wiki/Protocol_specification#Signatures:

  For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

i.e. the curve is

  y^2 = x^3 - 7

and the prime

  p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1.

See here for more information.


what happens if i sent bitcoin to a clubcoin address (address starts with a C)? what happens if i sent bitcoin to a clubcoin address (address starts with a C)? will i get refunded and get notified the transaction was invalid? please help me!

There are no Bitcoin addresses defined that start with a C (only P2PKH addresses which start with 1, P2SH addresses which start with 3, and P2WSH or P2WPKH addresses which start with bc1).

As a result, it is impossible to even create a transaction to such an address. There is nothing to refund of nofify - it's simply impossible to perform.


Is it possible (not feasible) to mine bitcoins with Bitcoin Core v0.21.1? Before you tell me, yes, I'm aware CPU mining is dead in 2021 and attempting to do so will likely just burn CPU time for no good reason.
However, my question is not whether mining is feasible, but whether it is possible with the (currently) latest version of Bitcoin Core, v0.21.1. From my understanding, it was possible in 2016, but the internal miner was "removed" in v0.13.0. Looking at the code, it's unclear to me whether it's still possible; miner.cpp is still present, for example. All that seems to remain is the "-generate" option. Does this option actually allow mining on mainnet?
If the answer is no: Isn't Bitcoin Core meant to be the reference implementation of Bitcoin? And given that, isn't it a bit odd that the reference implementation does contain one of the core components of Bitcoin, that is, the mining system? I understand it's pointless to do so, but as the reference implementation, shouldn't Bitcoin Core provide this feature regardless?

The setgenerate built-in background miner was removed.
There is however still a test-only on-demand miner, which will try to mine N blocks whenever requested by RPC (see generatetoaddress /generatetodescriptor/generateblock RPCs in recent Bitcoin Core versions). It is many times less efficient than even the built-in CPU miner was. Its only purpose is in functional tests (which use the "regtest" network that is permanently at very low difficulty).
The code you see in miner.cpp is additionally used as a backend for the getblocktemplate RPC, which is how pools and external miners communicate with bitcoind. It doesn't actually do any mining (as in hashing) itself, but provides block templates for others to do so, based on transactions in the mempool and the chain's tip block hash.
The -generate option to bitcoin-cli is just a wrapper around the internal generatetoaddress RPC, which is slightly more convenient (it requests an address from the wallet, and then miner to it). It is in theory usable on mainnet, but it obviously won't ever actually find anything (except with extremely small probability).


Api to automatically check the status of a BTC transaction My team is working for a community of members who make donations in BTC to support a cause from time to time. The donations the details are stored in a database and displayed on their personal profiles.

I am currently looking out for an api that will give me an information about the status of a particular transaction. i.e. whether or not the transaction is confirmed.

Almost all block explorer APIs have this functionality among their transaction API calls. You should check out their API documentation for more details and see which one is easier for you to use.
Here is an example from blockcypher API using the first non-coinbase transaction of one of the latest blocks:
https://api.blockcypher.com/v1/btc/main/txs/ca1662e85e137fae3ec13dace7f4bf64801a1ebdc8433150566b2ae838498a8a
Response:

{
  ...
  "confirmations": 2,
  ...
}

If the transaction is still in the mempool (unconfirmed) the value above shows as 0.

Note that if the purpose is unimportant things such as showing donations using a block explorer is fine, otherwise if the purpose is receiving payments (eg. for a sale) it is a much better idea to use a different method such as running your own full or SPV node.


send btc from specific input without running bitcoind Is there any third-party API allowing to send Bitcoins using specific transactions as inputs?

Back in 2013 I had to run bitcoind myself and build a raw transaction manually. But maybe it's easier now, after 3 years? Running bitcoind is not so cheap now, but I really want to forward a bitcoin payment from one address to others, also keeping it safe and clear.

You can implement your own very light bitcoin client. It should support version and tx messages: https://en.bitcoin.it/wiki/Protocol_documentation

So, you make TCP connection to any bitcoin node with white IP. You can choose blockchain.info, for example. Your light client sends version message, remote node sends you getdata message, and you send back your transaction in tx message. After that remote node verifies it and spreads to other nodes, and to entire network.

You don't have to care about safety. Noone can steal your bitcoins if you correctly generated raw transaction.


Recover Bitcoin Cash from Multibit I held Bitcoin in Multibit before the summer fork and later found that it wasn't supported anymore and installed Electrum. If I install Electroncash and use the same seed phrase, will I recover my Bitcoin Cash and should I also install Electroncash on a seperate machine to Electrum?

If the adress that the seed belongs to held any bitcoin at the time of the split,
then yes,

BCH should have been credited to the adress with that seed phrase, since they use the same adress format.

For absolute security, yes, you should. See https://electrum.org/bcc2.txt


Has the nonce used in mining been sized? In the mining process, everytime a block has to be confirmed, a certain hash with an incremental nonce is generated: If the nonce is a 32 bit number it can assume a value between 0 and 2^32 - 1. It gives about max 4.000.000.000  attempts on the same block to find the right hash. But if the target begins with 13 zeroes why isn't 2^32 too little to find the correct hash?

First of all, when 1 second has passed, the miner can just increment the timestamp in the header. This already gives us 4 Ghash/s rather than 4 GHash/block.

When this is not enough, and the nonce range is exhausted before a second has passed, the miner builds a new proposed block with a hash to search through. Specifically, the very first transaction in the block (the coinbase, which also receives the subsidy and fees) has a 100-byte area that essentially contains arbitrary data. So miners use this area as an 'extra nonce'.


Has anyone proposed a human only proof of work system? There have been suggestions of proof of work requirements that exclude GPUs or ASICS (or try to) but I was wondering if anyone had suggested a proof of work that is not suited to being solved by computer at all, so that the miners would be humans working on proving their own work done - work that cannot (currently) be performed by a computer in a competitive amount of time.

This would presumably need to be quickly verifiable by computer, but not independently solvable by computer.

If this hasn't yet been proposed, is there any apparent reason this would not work?

PoW needs to be hard to do but easy to verify (by a computer). There is very little left that humans are better at than computers (OCR, face and image recognition, IBM Watson [1] etc.). And probably nothing is easily computer verifiable.

One example are captchas. The ones that don't get read by OCR, simply get outsourced to children in our countries. You might say: still proof of human work, but there is no way for a computer to verify the result. On top of that that captchas don't satisfy some other requirements for PoW.

One such requirement is that the work is progress-free. Another: whatever the "puzzle" is, it must not be known beforehand as that would allow people to start the race early. This also implies there may not be one person or group of people that have access to the puzzles in advance as they would have to be trusted to not cheat (i.e. the system would not be trustless).

[1] https://en.m.wikipedia.org/wiki/Watson_(computer)


can we make a blockchain that works like torrent? Is it possible to make a blockchain system that allows you to download specific blocks from the blockchain instead of the whole blockchain?

In my case for example, I only need 1 giga of the whole chain, so why do I have to download all the blocks? I understand that this is done to make sure that the chain doesn't get tampered with and so on...

But is it possible to make it like a torrent file? where you can download only the files that you need, and no need to download everything with it.

...you can download only the files that you need, and no need to download everything with it.

To do this, you would need to trust that you are receiving the correct files (blocks) from your peers. If they lie to you and serve a false history, how will you know?

A full node downloads the blockchain so that it can independently validate the current state of the network, starting from the genesis block. By working through the network's history, the full node can verify for itself what the current state of the network is, without needing to trust any peers to not lie.

A lightwallet can download just the block headers (80 bytes per block) and use them to help verify that the wallet's transactions are authentic Bitcoin transactions.

But in both cases the node/wallet must have a full history of blocks/headers in order to not be trivially taken advantage of. So I think that an application which only downloads parts of the blockchain history is likely of little use, due to the potential for abuse of trust.


My transaction hasn't confirmed and it's been 9 days Transaction was initiated May 16, fee was 0.0001 and it's 226 bytes. It's 9 days later and it hasn't confirmed.

What is going on?
How do I get my BTC back?

EDIT:

Sorry, since I posted as guest it seems to not let me respond/edit as original poster. Here's the blockchain info: https://blockchain.info/tx-index/836b863d4099493d5599ab20024b10d6087f0ea662ffd2d1feea54acbd4a1195

It says May 20th, but I did send it May 16th

Your fee is extremely low. Blockchain is currently completely jammed up. Could you post transaction details so that any miners here can help?


What benefit does a non-mining client provide to the network? I know running a client will help propagate transactions around the network, but I also know a non-mining client will not contribute to the security of the network. Are there any other benefits of running a non-mining client?

A non-mining client will:

Propagate transactions to other peers, including the mining pools.
Propagate peer list, so everyone will have a wide list of peers to connect to.
Propagate the blockchain.
Help decentralise the network by doing all that.

So it essentially takes the burden off the bigger nodes by sharing data. It is especially true for the block information, as it can get quite lengthy.

This is a bit less true for clients working without forwarded ports, as they connect to few nodes, usually some bigger ones that are connected to many peers.


Cash reward for help retrieving my 0.5 bitcoin Mainly due to utter curiosity I purchased 0.5 bitcoin in 2013 and I have a piece of paper with 3 different passwords on. however, I've recently opened the wallet I had the coin in, but nothing shows up! Neither does it ask me for a password?  I've searched around for knowledgeable individuals who can guide me - in very layman terms - as to what process I need to go through in attempting to retrieve this 1/2 coin. As I'm very much in need of getting rid of the 1/2 coin I shall be more than happy to financially reward any person who can successfully retrieve it.

First off: DO NOT send those exact passwords to anyone offering help. Having those passwords may allow them to access and steal your coins.

If you open your wallet and see a zero balance, that is probably not a good sign if you haven't moved the coins yourself. Look at the history of transactions, and see if there are any that moved the coins to a new address. You need to figure out if the bitcoin has been moved to an address that you no longer control.


Bitcoin core addresses How many Bitcoin addresses can Bitcoin Core create? Is there a limit to number of addresses Bitcoin core can crate? Can I use one receiving address for multiple transactions?

How many Bitcoin addresses can Bitcoin Core create?

As many as you want. While the number of addresses possible is finite, it is essentially infinite as the number of possible addresses is extremely massive. There are 2^160 possible P2PKH addresses (1... addresses) and 2^160 P2SH addresses (3... addresses)

  Is there a limit to number of addresses Bitcoin core can crate?

No.

  Can I use one receiving address for multiple transactions?

Yes but that is not recommended. There are enough possible addresses that you can and should always use new addresses.


Partial Proof of Work in Pools Technically speaking a full PoW solution is one whose hash value is below a certain threshold value say V. It is not equivalent to saying that the hash value must begin with say X number of zeros (unless the threshold value is a power of 2).

My question is what is the usual practice in mining pools where one needs to submit partial proof of work to give a proof that he has worked on finding the block honestly? Lets say in some 'round' the miners in a pool have got their best (the least) hash values as v= v1,v2,..v_n. Is there a function that takes in v as an input and computes the reward for each of the miners ? Are there are checkpoint sort of system where say if the submitted share has hash value lying in between some range then that miner is categorised in that range. Once all the members are categorised into groups (which would reflect how powerful mining rigs they have), they can then be paid for their service proportionately.  Of course there is no need to categorise, like the way I mention but is it how it works in practice ? If so, how are the level checkpoints distributed ?

It depends on the payout system that they are using. Most payout systems use some sort of payment based on shares. A share is a Proof of Work that a miner submits to the pool. This Proof of Work is a "full PoW solution". But instead of having to meet the target for the Bitcoin network, shares just need to meet an easier target set by the mining pool.

Pools track how much work and how much hashrate someone has based upon the number, frequency, and difficulty of the shares submitted to them. They then use that to compute the payout amount. This computation depends on the payout system being used (e.g. PPS, PPLNS, etc.). The different payout systems calculate the final payout in different ways, but they all use this concept of shares.

The shares themselves are not categorized by their value. A pool knows what difficulty a particular miner is mining at so all shares are treated as being at that difficulty even if the value meets some other difficulty. The hashrate can be inferred from the number and rate of shares being submitted at a particular difficulty; the value of the hashes are not important so long as they meet the target.


Do Electrum Wallets accept BCH? I bought BCH from Bitcoin.com and provided an Electrum Wallet Address. The money did not arrive and Simplex, who arranged the transaction, advised that Electrum Wallets are only BTC even though the app does not mention this. Simplex sent me a link comprised of a http address on Bitcoin.com's website and the wallet address I originally provided which takes me to where my BCH is sitting but I do not know how to regain control of it and send it to a new BCH wallet. Bitcoin.com do not respond to emails. Can anyone help?

Electrum is a Bitcoin only application. This is directly stated by Electrum where it says it is a Bitcoin wallet. It does not say that it is a wallet for any other cryptocurrency. You cannot use Electrum for Bitcoin Cash.

To get your Bitcoin Cash, you will need to export your private keys from your Electrum wallet and import them into a Bitcoin Cash wallet. This may be easiest to do with Electron Cash which is a fork of Electrum but modified to work with Bitcoin Cash.


What is the largest number of blocks that have ever occurred in 1 hour? I have see questions about the longest delay between blocks and am aware of some blocks that occur in short succession. However I rarely see many blocks occurring very close to each other (which I suppose is normal since the average time between blocks is 10 minutes)

What is the highest number of blocks that have ever occurred in 1 hour?

How can I search the blockchain to answer this question for myself?

Most likely, you'll have to download all the block headers. The easiest way is to get them here. Note each block is 80 bytes so it's roughly a 30 MB download.

Next, what you're going to need to parse these block headers and make an array of timestamps. You can then write a program to parse these block headers and find the 3600-second interval that produced the most blocks.

Here's some sample code (Python 2):

data = open('blockchain_headers').read()
timestamps = []
for i in range(len(data//80)):
   timestamps.append(int(data[i*80+68:i*80+72][::-1].encode('hex'), 16))
max_height = len(timestamps)
best = 0
for i in xrange(max_height):
    for j in xrange(i+1, max_height):
        if timestamps[j] - timestamps[i] > 3600:
            if j - i > best:
                best = j - i
                print("%s: %s", (i, best))
            break

According to the program the most number of mined blocks in one hour is 61 blocks which started at block 65710 and ended at 65770 all within an hour on July 12, 2010.


Secret Key value for decimal versions over 127 After reviewing the address prefixes page on the wiki, I have noticed that in Bitcoin and other altcoins that the secret key / dumped private key header is always the decimal version + 128. So with a decimal version of 0 you will get a regular Bitcoin address starting with 1, while adding 128 to that you can find the private key which starts with 5 / L / K depending on the compression state.

Further example would be Litecoin's decimal version which is 48 while the secret key version is 48 + 128 (176).

So the question is: what about decimal versions between 128 and 255? I can see this going one of two ways.

Instead of adding 128, you subtract 128. So for decimal version 128 you will end up with a secret key of 0.
You round up to 255 in all cases of 128 and over.

I looked through the wiki and I couldn't find a reason as to why the secret key header is 128 greater than the public key header. One example that contradicts my two points above would be Unobtanium Coin whose public key header is 130 while the secret key is 224 (94 difference).

Is there any point at all for the secret key and public key headers being so far apart? Or is it fine to just have the headers be different in the first place, not necessarily 128 apart?

The reason is historical.

The 'version' byte was originally really just a version number. Satoshi probably intended to introduce more types of standard scripts to addresses. There were comments in the code about upgrading an address from one version to a new one even.

In that vision, to not restrict the options for future versions, I chose to make the private key just set the highest bit, leaving still 127 possible future versions.

Only one new version was ever introduced (P2SH), and since it is so powerful (it can encode any script indirectly), no other versions ever appeared.

So the short answer is: it does not matter at all.


Mining Altcoin with hash rate bigger than average network hash rate I am sorry if the question is off-topic but cannot find an answer to a simple question anywhere including btctalk.

So let's say a network hashrate of some coin using the X16R algorithm is 40 MH/s.  What happens if I start to mine with 2 8x1080 Ti rigs giving me about 200-220 Mh/s?

How can I calculate the percentage of total coins I get in 24h?

Suppose total number of coins mined in 24h is 7 million.

This depends on the altcoin-specific mining implementation.  However, assuming a mining model like Bitcoin, which runs on proof-of-work, you'd get the majority of coins mined in any given day if you have a higher hashrate than the rest of the network combined.

So, if there are 100 coins available to be mined per day, and before you start mining the network hashrate is 100 hashes per day, you'd mine 33 coins per day if you suddenly started mining at 50 hashes per day, assuming difficulty is adjusted on a per-block-basis.

Or, if the network hash rate is 40 MH/sec and you suddenly start mining with 220 MH/sec, and the number of coins issued stays stable, you'd get 84.6% of the coins mined, on average.  This assumes the proof-of-work required to generate a block of coins is recalculated continuously, which is not generally the case, but it makes the calculation easier, and at some point the network will adjust the difficulty to reflect the total hashrate.  If this was Bitcoin, where the difficulty is adjusted every 2016 blocks, you'd have a major advantage for up-to 2016 blocks, or whenever the next difficulty adjustment occurred.


Transaction with multiple outputs I have read that entire bitcoins received in one transaction have to be spend in other transaction. The actual amount to be transferred is deducted from the total bitcoins and the change is returned back to sender's bitcoin address.

Suppose, David Sends Alice the amount in form of two outputs, output0: 10 bitcoins and output1: 20 bitcoins in the same transaction. Now Alice wants to transfer 5 bitcoin to Eve. Does Alice has to spend entire 30 bitcoins, by transfering 5 to Eve and remaining 25 to herself?

Or can she choose any of the output e.g. output0: 10, transfer 5 bitcoins to Eve and change 5 bitcoins to herself? If this is the case, how is this tracked, as the hash of the David's transaction can be used to spend the output1: 20 bitcoins.

A transaction can have multiple inputs, so any of the scenarios you describe are possible.

Let's call David's transaction to Alice T, and its outputs T0 and T1.  Here are three ways Alice could make a transaction to achieve the desired results.

One input: T0.  Two outputs: 5 BTC to Eve, 5 BTC to Alice.  (In this case T1 remains available for Alice to spend in some future transaction.)
One input: T1.  Two outputs: 5 BTC to Eve, 15 BTC to Alice.  (T0 remains unspent.)
Two inputs: T0 and T1.  Two outputs: 5 BTC to Eve, 25 BTC to Alice.


Web API to retrieve difficulty changes I am looking for a website that allows me to retrieve the time at which each difficulty change happened. The time doesn't need to be accurate so a time stamp from the block will do. I want to fetch this information automatically every now and then, but I can't seem to find a webpage that provides an API for this.

http://blockexplorer.com/q/nethash/2016 provides the necessary information and shouldn't be too hard to parse. Every row corresponds to the first block at a given difficulty.


What happens when the 21 million cap is reached? I've just recently gotten into bitcoin, but I'm a bit confused about this 21 million bitcoin cap. From what I've read, computers on the bitcoin network validate transactions, which confirms the transfer of bitcoins between addresses. As a reward, these nodes receive bitcoins. My question is once the 21 million bitcoin cap is reached, doesn't that mean there's no incentive to validate transactions anymore? Won't the whole network essentially cease to function? Thanks!

Miners (who will no longer be mining, but will be validating transactions in the blockchain) will earn transaction fees. What those fees amount to or are to be interpreted as are hypothetical at this point, but might be imagined to be a transaction cost that ensures the security of the ledger.


Get invoice amount from payment request - LND REST API I'm using the REST API of my LN node to generate and pay invoices. I would like to know how to get the invoice amount/value in sats from the payment request I receive.

I found this : https://api.lightning.community/rest/index.html?javascript#v1-invoice, but I don't know how to get the payment hash.

Thanks in advance

I just found the answer : https://api.lightning.community/rest/index.html?javascript#v1-payreq

Use the endpoint v1/payreq to decode the payment request.

Exemple :

var fs = require('fs');
var request = require('request');
var macaroon = fs.readFileSync('LND_DIR/data/chain/bitcoin/simnet/admin.macaroon').toString('hex');
var options = {
  url: 'https://localhost:8080/v1/payreq/{pay_req}',
  // Work-around for self-signed certificates.
  rejectUnauthorized: false,
  json: true,
  headers: {
    'Grpc-Metadata-macaroon': macaroon,
  },
};
request.get(options, function(error, response, body) {
  console.log(body);
});

And the response :

{
    "route_hints": <array RouteHint>,
    "num_satoshis": <string>,
    "expiry": <string>,
    "description_hash": <string>,
    "timestamp": <string>,
    "features": <object>,
    "destination": <string>,
    "num_msat": <string>,
    "payment_hash": <string>,
    "payment_addr": <byte>,
    "description": <string>,
    "cltv_expiry": <string>,
    "fallback_addr": <string>,
}


What is the difference between mining with multiple workers vs single? Some bitcoin mining clients mine on a single worker, while other clients allow multiple workers.  How will either of these options affect mining production?

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

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

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


Does my wallet.dat file contain all wallets? I have backed up my wallet.dat file, but now I find myself wondering if bitcoin core stores all newly generated wallets in the same wallet.dat file. Of course this is after having accidentally deleted some files I shouldn’t have. Can I safely restart my computer and download bitcoin core again, and load the old wallet.dat file or should I have seperate wallet.dat files for every newly generated wallet?

A wallet contains many addresses. An address is not the same thing as a wallet.
When you create a new address with Bitcoin Core, it is stored in the wallet that you are actively using at that time. This means it is stored in the wallet.dat file.


I want to create a P2TR (pay-to-taproot) address but I just need a key path spend, not a script path spend. How do I create the P2TR address? I want to create a P2TR (pay-to-taproot) address but I just want access to the key path spend, I have no use for the script path spend in this specific example. Do I hash an arbitrary string to use as the Merkle root for the script path spend?

BIP 341 (BIP-Taproot) discusses this example where you don't require the script path.

If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path.

The BIP also explains here the rationale for this.

If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties. This allows to bypass the multiparty policy and to steal the coins.

The Bitcoin Optech workshop on Taproot explains that you calculate the tweaked public key using:
Q = P + H(P|c)G

where
Q is the tweaked public key
P is the initial public key (P = xG where x is the private key)
H is the hash function
| is concatenation
c is the commitment to the script path spend
G is the generator point

If you don't need the script path spend you can calculate the tweaked public key using:
Q = P + H(bytes(P))G

where bytes(P) is the serialization of P as defined in BIP 340 (BIP-Schnorr).
This tweaked public key Q will be your Taproot (P2TR) address. Remember we don't hash (tweaked) public keys with Taproot (SegWit v1) like we do with P2PKH, P2SH, P2WSH (SegWit v0).


Backing up wallet with pen and paper, destroying electronic copy, restoring from keyboard -- how? I have bitcoinQT with some coins on it.  I want to use the internet on a regular basis from this computer.  I do not trust the authors of internet applications and commercial operating systems.  I especially do not trust the manufacturers of printers.  I also do not trust that there will never come a day when burglars (or polite young men with a writ, same thing) with guns break into my home and take away all computing devices and storage media they can find.

It is my intent to use a pen and paper to write down public key and address, and destroy all trace of bitcoin addresses currently holding value from all electronic media.  That which is not stored electronically - at all - is secure from all possible electronic snoops and all possible thieves of equipment, as well as from equipment malfunction.  That which does not exist, even in encrypted form on storage media, cannot even be shown to have ever existed.

But having done so -- what exactly do I need to type, at keyboard, into a text file, to create something that bitcoinQT, when started with no known wallet on the machine (as though for the first time) knows how to import?  What exact format?  And how exactly do I tell bitcoinQT to import it?

The Satoshi bitcoin client has a dumpprivkey command available in the console, which outputs an encoded string of about 50-60 alphanumeric characters.  That should be pretty easy to write down, and it can be reimported with the importprivkey command.

But if you're really paranoid, why ever have your private key on a computer at all?  Flip a coin a bunch of times to generate some random bits, and then run the ECDSA keypair generation routine with a paper and pencil!  Hash the public key (you can use a computer for that part) to get your address, and transfer all your bitcoins to that address.  If you want to spend them someday, run ECDSA's signing algorithm by hand to make a raw transaction, key it in, and put it on the network.

Of course, stealing the piece of paper where you wrote down the key is probably a lot easier than decrypting an electronic copy.  It seems to me your trust is a little misplaced.


How do I set up a free Bitcoin eStore I want to sell digital products (eBooks) using Bitcoin, and I want products to be instantly available after purchase. What could I do?

Coinbase has shopping cart plugins that can integrate with many existing e-commerce web apps without you having to write any code. See here: https://coinbase.com/docs/merchant_tools/shopping_cart_plugins.

In case you were wondering, an "e-commerce web app" is a pre-build shopping website that is analogous to Word Press for publishing. There are a few open source (free) options for this. Just google "open source e-commerce web app".


no output on gettxout method [All Blocks Are Counted] litecoin-cli gettxout "9d56b3bf179a988873fc2162d70bba44849ef822764c9049a0f722b5fdc9acc1" 1
This is the command im using to get information about a transaction.
litecoind -txindex=1 -daemon -conf=/home/litecoin/.litecoin/litecoin.conf -reindex -rpcuser=cryptosensei -rpcpassword=foo_420 -rpcport=9332 -rpcthreads=1000
This is the command i use for starting up my daemon. with the -reindex it should not re-verify the blocks. So im wondering why im getting null.
If anyone knows what the issue let me know. Also here is the response of getnetworkinfo & getblockcount
getblockcount
litecoin@Debian-913-stretch-64-minimal:/root$ litecoin-cli getblockcount
0

getblockchaininfo
litecoin@Debian-913-stretch-64-minimal:/root$ litecoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 0,
  "headers": 526188,
  "bestblockhash": "12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2",
  "difficulty": 0.000244140625,
  "mediantime": 1317972665,
  "verificationprogress": 1.737314343731834e-08,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000100010",
  "size_on_disk": 2217395400,
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": false
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": false
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "defined",
      "startTime": 1485561600,
      "timeout": 1517356801,
      "since": 0
    },
    "segwit": {
      "status": "defined",
      "startTime": 1485561600,
      "timeout": 1517356801,
      "since": 0
    }
  },
  "warnings": ""
}

Assuming this is identical to Bitcoin Core.
This is somewhat confusing, but it simply means that UTXO is spent. It is reporting "nothing" as output.


How to implement Multisig transaction without using OP_CHECKMULTISIG I've learned that OP_CHECKMULTISIG is a Bitcoin builtin opcode to validate Multisig transactions. Can I write Bitcoin script to validate the Multisig transactions without invoking OP_CHECKMULTISIG? If so, what do I need to change in the redeemScript?

Yes, you can use a redeemScript that has a lot of OP_CHECKSIGs and boolean operations. You would have to enumerate all possible combinations of signatures however.

As a simple example, if you used a 2-of-2 multisig, traditionally your redeemScript would be

OP_2 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG

and the scriptSig is then

OP_0 <sig1> <sig2> <redeemScript>

Without OP_CHECKMULTISIG, your redeemScript would be

<pubkey1> OP_CHECKSIG OP_SWAP <pubkey2> OP_CHECKSIG OP_BOOLAND

and the scriptSig would be

<sig2> <sig1> <redeemScript>

For more complex multisigs with more keys and m-of-n, the scripts will be much more complicated with more OP_SWAPs, OP_BOOLORs, and OP_BOOLANDs.


How exactly does "CoinDance" determine the current number of public Bitcoin nodes? On this URL: https://coin.dance/nodes
It says how many public Bitcoin nodes are currently active in the world, and how many Bitcoin Core ones.
While it's good that I can grab these numbers from that webpage, I'd like to know how exactly they determine this, and if it's simple, I'd like to calculate it myself rather than relying on a third party which could disappear tomorrow or lie to me or have a bug or anything.
Is this simple to determine? What steps have they likely taken to calculate this? Does it involve scanning every public IP address in the world repeatedly and checking for listening Bitcoin ports? If so, I'll probably leave it to them as I don't need to emit that kind of insane amount of traffic from my home... not to mention it would probably require me to use tons of IP addresses lest I want to get banned from various network and thus get inaccurate statistics.
Or does Bitcoin Core itself have this information baked in? Does the Bitcoin network send around an integer saying how many nodes there are to each other as part of the protocol, and I can just use the RPC API to my local Bitcoin Core to get this info?

Does the Bitcoin network send around an integer saying how many nodes there are to each other as part of the protocol,

No.
See https://en.bitcoin.it/wiki/Protocol_documentation
So far as I can see, total counts of active nodes are not part of any message but there are potentially useful messages such as:

getaddr
The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network.

By sending this message to all known but previously uncontacted nodes, it is possible to discover more previously uncontacted nodes you can send this message to until the responses only contain previously contacted nodes and all the nodes you know of are either contacted nodes or unresponsive nodes.

I'd like to know how exactly they determine this,

CoinDance don't say.

As Davidson Souza's later answer reports, at least one website (Bitnodes) uses the getaddr message to approximate the number of all currently accessible nodes.


Benchmarking on Hyperledger Fabric Is there any public benchmarking code and results for Hyperledger Fabric v1.0 blockchain?
IBM claims a transactions rate of 3500 tps, but I am not able to find any public code of the benchmarking experiments.
Paper link: https://arxiv.org/abs/1801.10228

You can run Hyperledger Caliper https://www.hyperledger.org/projects/caliper/ , a benchmarking tool that supports Hyperledger Fabric (IBM), Hyperledger Sawtooth, Ethereum, and other blockchains.

Click on "Get the Code" link in the link above, or go to https://github.com/hyperledger/caliper for source code. It's thousands of lines of code, including benchmark blockchain apps, so that's too much to post. The original link above has documentation and is the main Caliper project page.


Why do non-mining nodes listen to transactions? I still don't understand why full but non-mining nodes listen to transactions. The validity of the transactions are ensured cryptographically. So what advantage does it give to either me or to the network? What am I supposed to do with that info when I get a live transaction? In my understanding, a full node should only listen to new blocks, unless it is also mining at the same time.

There are multiple reasons.

Wallets Maybe the node operator also has a wallet, and is interested in seeing unconfirmed transactions that pay him. It's generally discouraged to have a business depend on irreversible actions taken based on unconfirmed transactions, but this is not true for everything. You could for example start preparing a shipping order as soon as an unconfirmed payment comes in, but verify that the transaction is confirmed before it actually goes out the door.
For fee estimation Maintaining a set of unconfirmed transactions in a way that lets you predict what will be confirmed in the near future (specifically, by running the same code as miners do) gives you insight in how fast network transactions with certain properties get confirmed. You cannot base this information purely on what you see in blocks, as that can be trivially gamed by miners (e.g. by stuffing their own blocks with a number of very high fee transactions).
For network propagation Modern block relay solutions (like BIP152 Compact Blocks, FBRP, FIBRE, thin blocks, ...) rely on the fact that most transactions in a block can already be known to the receiver ahead of time, if they maintain a pool of unconfirmed transactions. These protocols massively reduce the time needed to get a block relayed across the network.

Bitcoin Core since version v0.12.0 supports the -blocksonly flag, which disables all downloading and relay of transactions. It comes with a bandwidth reduction, but also loses the benefits listed above.


PCI-E v1 2 and 3 differences in mining? Is there any difference in hashrate if I mine from mainboard with pci-e v1 v2 or v3. Also is there difference if I use x1 slot with extension to x16?

No, it does not matter. Cheap 1x-16x extensions may either burn out or not work properly though, a powered one is essential.


What are Fidelity bonds and how do they work in Joinmarket? I am interested to know the basic concept of Fidelity bonds in finance and how will it be used in Joinmarket.

What are Fidelity bonds?
Fidelity bond is a type of insurance contract designed to protect from losses caused due to forgery, theft etc. Normally used by employers in form of business insurance which generally covers the dishonest activities performed by its employees.
Background:
First ever mention of fidelity bonds. The idea is basically invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
Old idea for combining fidelity bonds with mixers: https://bitcointalk.org/index.php?topic=172047.0
Suggestion that is very close to the fidelity bonds idea in Joinmarket. He talks about requiring a deposit from makers, but nobody is able to come up with a way to make such a deposit decentralized and trustless: https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1
Adding fidelity bonds in Joinmarket:
Chris Belcher has opened a pull request which adds Fidelity Bonds in Joinmarket: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/872
Almost everything is included in the commits and reviews can be helpful in removing bugs (if any) and merge it soon. The only major feature missing is having yield generators announce fidelity bonds held in cold storage.
The changes to the joinmarket protocol are backward-compatible. You can read docs/fidelity-bonds.md for more details. Below is a summary from it:

Fidelity bonds are a feature of JoinMarket which improves the resistance to sybil attacks, and therefore improves the privacy of the system.

A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. Takers in JoinMarket will have a higher probability to create coinjoins with makers who publish more valuable fidelity bonds. This has the effect of making the system much more expensive to sybil attack, because an attacker would have to sacrifice a lot of value in order to be chosen very often by takers when creating coinjoin.

As a maker you can take part in many more coinjoins and therefore earn more fees if you sacrifice bitcoin value to create a fidelity bond. The most practical way to create a fidelity bond is to send bitcoins to a time-locked address which uses the opcode OP_CHECKLOCKTIMEVERIFY. The valuable thing being sacrificed is the time-value-of-money. Note that a long-term holder (or hodler) of bitcoins can buy time-locked fidelity bonds essentially for free, assuming they never intended to transact with their coins anyway.

The private keys to fidelity bonds can be kept in cold storage for added security. (Note: not implemented in JoinMarket yet)

Financial mathematics of JoinMarket fidelity bonds: https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b

How many coins to lock up and for how long?

Fidelity bonds UTXOs are valuable as soon as they confirmed. The simplified formula for a fidelity bond value with locked coins is: bond_value = (locked_coins * exp(interest_rate * locktime))^2

At any time you can use the orderbook watcher script to see your own fidelity bond value.

Consider also the warning on the bitcoin wiki page on timelocks

At the time of writing fidelity bonds are not deployed yet in the wild, but I would recommend locking as many coins are you're comfortable with for a period of between 6 months and 2 years. Perhaps at the very start lock for only 1 month or 2 months(?) It's a marketplace and the rules are known to all, so ultimately you'll have to make your own decision.


Bitcoin Public Key To Address Uncompressed So after searching for HOURS on here and overall on the internet, I haven't managed to find an answer to my question so I'll ask here.

So I've been trying to convert a public key into an address. I've been writing all the hashing algorithms, and tested them with online hashing websites, so they are working. Here is my code:

function getBTCAddress(public_key)
{
   var __SHA = SHA256_hash(public_key);
   console.log("__SHA: " + __SHA);
   var RIPEMD = RIPEMD_160(__SHA);
   console.log("RIPEMD_160: " + RIPEMD);

   var new_SHA = SHA256_hash(RIPEMD.toString());
   console.log("new_SHA: " + new_SHA);
   var _new_SHA = SHA256_hash(new_SHA);
   console.log("_new_SHA: " + _new_SHA);

   var checksum = _new_SHA.slice(-8, _new_SHA.length);
   console.log("checksum:" + checksum);

   var almost_address = "00" + RIPEMD.toString() + checksum;
   console.log("almost_address:" + almost_address);

   var buffer = Buffer.from(almost_address, "hex");

   return BS58.encode(buffer);

}

For some reason it is not giving me the proper results. I'm wondering, what are the exact steps of deriving an address from a public key?

For those of your who are wondering here is what my code is doing:

  checksum = SHA256(SHA256(RIPEMD160(SHA256(public_key)))) <-- get last 8 bytes

  almost_address = 0x00 (network byte) and RIPEMD160(SHA256(public_key)) and checksum <-- compacted into 1 string

  address = base58(almost(address)

You're hashing the string representation of things, not the actual hash itself. Hash the bytes of the hash, not the bytes of its string representation.

All of the should operations are on the bytes themselves, not the hexadecimal representation of those bytes which is what you have done.


Received bitcoin but can't send I am new and using multibit 0.5.14. I have received 2 bitcoins in one transaction, and 0.005 in another. However, after over an hour they are still not spendable. I checked the status and it says "seen by 4 peers Pending/Unconfirmed. When I check on blockchain.info, there are 17 confirmations for that block. How do I know if something has gone wrong? Is there something else I should do to make my bitcoin 'spendable' or do i just have to wait it out longer?

You can click Tools-> Reset Blockchain and Transactions.


What subjects do I need to study before I am capable of understanding the mathematical problem being solved in Bitcoin mining? I am a post graduate electrical engineering student, specialising in digital electronics. I would like to foray into ASICs for bitcoin mining. But first I need to understand the mathematics of Bitcoin mining. What subjects do I need to study to get a good idea of what my ASIC has to tackle?

Your ASIC basically only does one thing: SHA256 hashing. It gets a block template, hashes it, compares the result as if it was a number to some target to see if it is less than the target, if not it modifies the block slightly, hashes again, repeat...

So all you need to understand is the SHA-256 hash algorithm. It is not overly complicated, you will need to understand some logical bitwise operations like AND and XOR, hopefully understand how bits, bytes, hexadecimal, etc. are all related, it involves some bit-rotations which should be mostly self-explanatory, how modulo works, and maybe a couple of other similar-level concepts. As a postgrad digital electronics engineer I expect most of these concepts are bread and butter to you, so you should be ok :)

Of course, that's just to read through how the algorithm works, understanding why certain things are done in the algorithm is much more complicated and would require a lot more reading about hash functions and cryptography. But understanding why something is done is not a requirement to use it.

Wikipedia page for SHA-256 which contains some pseudocode is found here: https://en.wikipedia.org/wiki/SHA-2


What does the little-endian notation improve for Bitcoin? In another thread I read that the little-endian notation speeds things(?) up. Has someone info on what exactly it improves for Bitcoin?

Almost all CPUs these days work natively in little-endian. To operate on big-endian numbers, additional byteswap instructions are needed.
For most things, I think this effect is negligible. Network protocols need a convention to represent things, and Bitcoin's creator picked one. The actual choice barely matters.


Why did BitcoinEXpress plan a 51% attack on Namecoin? I don't understand this post.

What is "ArtForz modified exploit"?

What does "Gavin's patch will not work for the exchanges" mean?

Any more important details I'm missing?

This post by ArtForz on the forums explains the attack:

https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772

Quote: "By exploiting the fact that retargeting ignores one block interval every period, it's possible for an attackers' fork chain to "jump backwards in time" and create lots of blocks at low difficulty without running nTime off into the far future."

This attack has been proven to work on GeistGeld (which uses 10 second blocks and 16 block retarget intervals). It was rather easy there, because of the low intervals and because the developers "forgot" to adjust other constants regarding timing and clocks. They since made it much better.

Now it seems it will be tried on namecoin, with the goal of making bitcoin more secure.