Is a private key used up when part of the bitcoins it controls are sent?

False, as you've described it here, because private and public keys work a little differently than that.  The underlying math is tricky, but I'll try and give a common sense explanation in everyday language instead.

Imagine that there was a special metal called Cryptonium, harder than anything else on earth and completely indestructible.  No one else knows it exists, much less how to make things out of it.  Let's also say you had a special machine which could make plaques out of Cryptonium, with raised letters on them saying whatever you wanted.  Obviously, you would keep the existence of this plaque-making machine a closely guarded secret.  You probably wouldn't even want anyone to know it was you that owned it.  But you still want to share this exciting discovery with the world, so you secretly produce a message that says "Behold, a new and indestructible metal!"  Then, late at night, you sneak into the middle of town and put the Cryptonium plaque up in the town square.

The next day, everyone gathers in the town square to wonder at this amazing new plaque.  They take turns bashing at it with the hardest, sharpest, heaviest things they can find, and the plaque remains perfectly unscratched.  "Sure enough," they figure, "it's indestructible."

You decide to use the secret machine to write more things, helping out the townspeople and gradually earning a reputation as a trustworthy and reliable source, even though nobody knows who you are.  But a few months later something terrible happens.  New plaques start showing up in town during the night, and they are fakes!!  Someone else is taking advantage of your reputation to spread false and misleading messages!  They don't have your special machine of course--they're making their plaques out of platinum, and it's only almost indestructible.  But the two metals look the same, and the townspeople don't know the difference.  What will you do?

You could announce yourself to the townspeople, show them the machine, and tell them the new plaques are fakes.  They might believe you, but your machine wouldn't be a secret anymore.  So instead you do something really clever.  You use the machine to make a small, square plaque in the shape of a hammer's head.  On the plaque, you put the message "This hammer will destroy all fake plaques." Then, you attach a handle to the hammer head you've made and leave it in the middle of town the next night.

Now, the townspeople can simply use the hammer to break all the fake platinum plaques.  Sure enough, the false and misleading messages are all easily destroyed, while the ones you've produced are able to withstand the hammer's force.  Your reputation is preserved, and your secret was never revealed.  Together the hammer, the secret machine, and the plaques form an unbeatable system that lets you send messages which could only have come from you--without revealing who you really are.  Not bad, hey?

In many ways public key cryptography works like our imaginary Cryptonium metal.  It's made up of three parts, and it gives other people a way to be certain a message came from you without you having to reveal your identity or your secret way of making messages.  Like the Cryptonium system, you need all three components to make the system work.  These three parts are your public key, your private key, and your signatures (which you can make as many of as you like, signing all different messages.)  In our story, the private key is like the secret machine, the public key is like the hammer, and the signatures are like the plaques.  In reality public key cryptography is more complex than I've described here, and if you want to learn more about it you can check out this course from Khan Academy.  However this example should be good enough to understand how private and public keys are used in Bitcoin.

First, nobody else ever sees your private key. Instead, like the secret machine, you use your private key to make signatures (like the plaques) that people can be certain came from you.  Each person (and each bitcoin address) has both a public and a private key, which share a special mathematical relationship, and the public key (like the hammer) is what other people can use to verify your signatures are real.  When you send a Bitcoin transaction, you don't give away your secret machine--you only use it to make a message saying who you're giving the bitcoins to.  This signed message, or signature, couldn't have come from anyone else except the owner of the address, so then everyone knows the transaction is real.

Second, private keys don't come from miners--they come from you.  You're the one who secretly chooses a random private key (the Bitcoin software does this for you), and that private key was used to figure out your address (which is basically a version of your public key) before anyone ever sent it some bitcoins.  Miners never have it to begin with.  They only see your transactions (signatures) and your receiving address (public key).

Finally, just to confuse things a little bit, you have to use up a whole transaction at one time.  So if someone sent you 10 bitcoins, and you want to send someone else 5 of them, you actually send out a transaction that takes all 10 that you received, sends 5 to the other person's address, and 5 to another address of your own (this is called the "change" from your transaction).  Bitcoin does this so that other people can't tell which part of the transaction is what you sent and which part is the change (nobody knows which addresses belong to the same person).  It helps protect your privacy.  But if you wanted to, you could send the change back to the same address, because your private keys are still safe.  You'd just have to use a different client than the default Bitcoin client, because it doesn't have a way to do that.  All of this happens behind the scenes, which is why your balance still shows as 5 bitcoins after you do this.  Bitcoin stores all your different addresses and private keys in something called a wallet, and the balance is the total bitcoins owned by the wallet.  So it keeps everything simple up front!

Make sense?  Hope it wasn't too long, but I wanted to try and make the public/private key thing more clear.


Virus warning in Bitcoin [cash] ABC client?

Yes, that's very usual and expected.

It is not surprising to have Bitcoin-related code in Bitcoin Core(-forks), but the malware analyzers don't understand the purpose of Bitcoin code.

Here's a real software with a Bitcoin miner (utorrent 3.4.2): https://www.virustotal.com/#/file/0e7e8526e8c4ab3c3dc938b1bb042bda07f464390a919c7f3f30caadec156549/detection

The same happens for Bitcoin Core:


What are the implications of a decreasing trend of MtGox "ask" depth compared with "bid" depth?

There has been a rally in price of 10% or more since May, and there is constant supply of new bitcoins entering the market, so some of the cash from the order book has since moved into bitcoins.

But no doubt, a thicker order book (reflecting lots of buying interest) lessens the risk of a selloff.

When Mt. Gox's BTC/USD represented 80% or more of the trading volume for all currencies at all bitcoin exchanges it was vulnerable to manipulation during times when there wasn't a thick order book.

Because it takes a length of time to move funds into the exchange (from hours for a wire transfer to several days for Dwolla, for instance) an aggressive seller can profit from manipulation.  The method is to sell heavily into a small order book, and then put in bids there at the lower level to buy back coins at from "weak hands" who fear a further selloff and sell into those bids.  By the time additional USD funds arrive at the exchange from other buyers, the manipulator might have been able to buy back the entire number of coins sold but at a lower price.

Now that the BTC/USD market at Mt. Gox has dropped to a threshold near the 50% mark (of all currencies traded on all markets), a manipulator no longer has a vice-like grip on all bitcoin markets by controlling just the BTC/USD at Mt. Gox.

Instead of the Mt. Gox BTC/USD market leading the price moves, it now sometimes lags.  Thus during a selloff, trading markets at other exchanges might have some order depth at higher levels and thus the manipulator doesn't get to buy back as many bitcoins because the sellers go elsewhere to get a better price.


I think you have misunderstood something.

The point of generating a new address for receiving a payment is that this address is not connected to any other address, and when it is eventually used to make a payment - that is where the trail ends. ie a new receiving address becomes a sending address.

If you do this systematically, and never send coins to the same address (either through change, or by consolidating your holding into one address) then you have pretty good anonymity.


What unique business models has Bitcoin enabled?

The only thing I can think of is Mike Hearn's idea for Smart Property. This would allow the ownership of physical assets to be digitally exchanged and stored in the block chain. Other than that, I think Bitcoin mainly improves the efficiency of many, mainly digital, business models.


There is this list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Bitcoin_forks

Bitcoin Cash (Forked at Block 4785591, 1 August 2017)
Bitcoin Gold    (Forked at Block 491407[2], 24 October 2017)
Bitcoin Diamond (Forked    at Block 495866[3], 24 November 2017)
UnitedBitcoin (Forked at Block    498777[4], 12 December 2017)
BitcoinX (Forked at Block 498888[5], 12    December 2017)
Super Bitcoin (Forked at Block 498888[6], 12 December    2017)
BITCOIN HOT (Forked at Block 498848[7], 12 December 2017)


Can I Hook Up RX-460 to Regular PCI Slot via PCI-E Riser

No.  PCI and PCI-e are two entirely different things.  PCI is a more traditional parallel data channel, while PCI-e is a serial data channel (that can have multiple parallel "lanes").

You cannot plug PCI-e devices into PCI sockets.

If you're desperate, you can try the mechanism specified here, no guarantees though :)

https://www.youtube.com/watch?v=5vDHACwXSxE


What happens when the nonce field overflows?

Changing the timestamp is one way, but the more scalable method is to change the "extraNonce" field of the generation transaction, which changes the block header's Merkle root.


Which bitcoin wallet allows me to generate and export a large number of addresses?

It is not necessary to download blockchain to generate address. Use an HD wallet like electrum, so that you can regenerate wallet using seed even if you lose private keys.

To generate addresses http://docs.electrum.org/en/latest/faq.html#how-can-i-pre-generate-new-addresses
To export addresses use electrum command line http://docs.electrum.org/en/latest/cmdline.html


Where is the Mycelium wallet file stored?

For Mycelium, the actual file that contains the encrypted keys are in the sqlite3 file. You can see in the source code that though there is in-memory storage, it's used mostly for testing and that the main way in which Mycelium data is stored is in a sqlite3 file. Sqlite, if you aren't familiar, is a very simple relational database that contains the whole database in a single file.

You can see the actual relational database table layout in the source code.

To answer the question about exactly where the wallet is, mycelium does not have the installLocation attribute and therefore is only going to be stored in internal storage, or on the phone itself.


Weird script stack entries at block #227837?

Coinbase inputs have no requirements to be valid scripts, or any particular data at all other than the block height defined in BIP34.


How can i get balance of bitcoin address not exist in my wallet?

If you have bitcoind running, you can get balance without using bitcoin-abe.
Basically you need addrindex enabled in bitcoin. A simple script can get all transactions of a given address and then calculate the balance. You can use https://github.com/cnu1439/blockchain-utils


Determine inputs/outputs of a transaction before sending

If you are constructing your own transactions (rather than letting a wallet application do it for you), then you get to choose which inputs and outputs you use in the transaction.  For that matter, you also get to choose the fee for the transaction, since any leftover from the sum of the inputs minus the sum of the outputs is the mining fee.  Just remember that leaving too low of a fee will result in long delays of unconfirmed transactions.

Based on your needs, you can choose to use different coin selection algorithms.  A coin selection algorithm's purpose is to select inputs from the pool of UTXOs that you control.  Selecting too many for a single transaction will result in a higher fee.  However, refusing to use smaller UTXOs will leave your entire pool comprised of small ones, forcing you to use them (and pay higher fees) until your pool recovers.

There are pros and cons to different algorithms, especially when you are concerned with fees, so be sure to understand the ramifications of your decision.  A good place to start might be @Murch's presentation at Scaling Bitcoin.


Is my 2FA not working, or do I not understand it?

Go to Account Settings, Security.
The default is to ask for 2FA only over $100/day.
Change it to ask every time.


Two threats to Bitcoin: Quantum Computing and Mining farm seizures - what new BIPs are needed before it is too late?

How resistant is bitcoin blockchain against physical attacks? Contrary to other consensus mechanisms, Bitcoin's PoW model is dependent on massive Mining Farms with tons of ASIIC hardware. These farms are known to everyone, especially the government of respective country.

Bitcoin's protocol is designed to adjust to increases and decreases in network hash rate. There is a difficulty adjustment for this purpose. If a number of mining farms all went offline in an instant it would result in higher confirmation times until the difficulty adjustment kicked in two weeks later. Although disruptive in the short term it would have no greater impact than that.

The bitcoin network is not using signatures or encryption methods that are especially suited against quantum computer attacks. Especially Bitcoin's ECDSA and the PoW mining process would become easily vulnerable with quantum computers.

The Bitcoin protocol is using elliptic curve cryptography as are all internet security protocols and banking security applications. As Pieter Wuille states here:

Quantum resistant signature algorithms do exist, but they all rely on very large signatures - which may make them unfeasibly expensive for purposes like Bitcoin.


is target a 256 bit field or a 32 bit field

The target is a 256 bit integer. However it is stored and represented in block headers as a 32 bit integer. This is a compact representation of the actual 256 bit value.

Operations involving the target are done as both 256 bit integers. However because the target is stored as a 32 bit integer in the block header, calculations involving the previous block use the 32 bit integer expanded out to the 256 bit representation. Unfortunately this compression is lossy so some data is lost in this process.

The code relevant to target adjustment can be found here: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp


How does the blockchain know if its block hashes have been tampered?

Changing the previous block hash in all of the subsequent block hashes will change those block's hashes too. They become different blocks and are treated as different blocks by nodes. When other nodes try to verify those other blocks, they will extremely likely compute a block hash which does not meet the Proof of Work requirement, and thus those blocks would fail validation.
The way around this is for the attacker to recompute the Proof of Work, but then that takes a lot of time and computing power and is thus difficult to do.


A transaction is confirmed by including it in a block. This means that you have to mine a block which includes the transaction. You can do this using the generate command.


Can I start a Bitcoin Private Node using bitcoin-qt?

bitcoin-qt -regtest -port=11111 -datadir=.\data -rpcport=11112


What are the possible Doomsday scenarios for the 2016 Halving from 25 to 12.5 BTC per block solved?

I think you might be referring to the hypothesis that a large portion of the mining power would switch off right at the halving. This is theorized to kick off a chain reaction:

Lower network hash rate causes slow blocks
Slow blocks increase block space competition
Block space competition increases fees
Increased fees push users off network to competing coins
…
Bitcoin fails

I think this theory is a bit of a slippery slope:

Hashrate

More than half the hashrate has only come on-line in the past half year. Mining companies should be well aware of the Halvening and I'd expect them to consider it in their financial planning. Some might miscalculate its effect, but it shouldn't come as a total surprise.

I'd expect investments into mining hardware to slow down in the time before the Halvening, and mining companies to keep close watch on their revenue immediately after it. They'd first turn off the least efficient hardware, which reduces their cost the most and also has the least impact on their hashrate. Every piece of hardware that gets turned off makes the remaining hardware more profitable. It may dip, but gradually would find a new balance.

Similarly, some altcoin might be more profitable suddenly. Yet, as mining power switches over, competition for that altcoin's revenue gets more fierce, while the reduced hashrate in turn makes Bitcoin more profitable for the others.

Block space
More competition to enter the blockchain would not end the world. In some subreddits the narrative seems to be that full blocks would necessarily cause unconfirmed transactions to grow limitlessly. However, it seems much more likely that people would consider their transactions more carefully, and block space would be used more efficiently. E.g. major Bitcoin companies that do two transactions per payout would probably find a way to save some of those, mining pool minimum payouts might increase, you'd combine transactions where possible. Besides, it seems likely that SegWit would be deployed by then and block space might be less of an issue in general.

Competing coins
Bitcoin is the coin with the greatest security and utility. Paying premium for a feature that you don't need seems silly. If people move to other coins for low amount transactions, one or two of them might see a renaissance, but they wouldn't be able to overtake Bitcoin because they'd have all the same problems with scaling, governance, and software evolution once they get a similar amount of attention.

TL;DR: If the network's hashrate dips, it seems unlikely to happen instantaneously. It may decrease a bit over time. The resulting pains would incentivize more efficient behavior, but I don't see how they'd cause Bitcoin to fail.


Where can I find some reputable resellers of Casascius.Physical Bitcoins?

Casascius has resumed selling individual and rolls of coins on the official website, https://www.casascius.com/. Individual coins will be sold for a limited time only.

It is still possible to save money on individual coins by buying through resellers.


How long for wire transfer from MtGox to Australian Bank?

mtgox support desk: "Situation as of 24-Nov-2013: We are currently processing withdrawals requested 5 weeks ago." so it seems that you may get your money at the middle of december.


Can bitcoin and altcoin co-exist in sidechain? If Yes, strategy

No, you cannot set the exchange rate between your private coins and the pegged coins, because you cannot issue the pegged coins yourself.

The chain the pegged coins come from do still keeps track of how many coins were moved out, and there can't be more that come back. That would violate the sender chain's consensus rules.

So say your sidechain holds 100 pegged BTC, and 100000 private coins. If these were cheap to create, people would immediately convert them to 5000 pegged BTC using your 1:20 exchange rate, and try transferring them out. However, only 100 BTC can move back, because from Bitcoin's point of view, that's all what exists. You get effectively get a "run on the bank", and the peg mechanism fails afterwards, because you did not respect the rule that you can only have as much pegged BTC as there are real BTC backing it.


You should use full nodes on both sending and receiving end

Sending Tx

Use the -connect option to broadcast your tx through selected neighbours. Use https://bitnodes.21.co/ to find neighbours. Use the wallet commands in bitcoind and send a transaction to address in your own wallet

Receiving Tx

Use -walletnotify option in bitcoind to get notifcation of incoming wallet transaction. I don't think it is easy to receive mempool tx without validating the blockchain first. Anyway this is one time effort, once you have it synced on one node you can easily copy the whole .bitcoin directory to other nodes.

About language you don't need to use C++ at all. For sending tx you need to do RPC calls. This can be easily done using bash commands or you can use https://github.com/jgarzik/python-bitcoinrpc in python. For receiving, the notify script can be any language php/python, it will just get your tx id as parameter and then you can do whatever you want.

Don't worry about spam. Its difficult to spam the network unless you have lots of bitcoins to waste in tx fees. Just make sure you put enough tx fees so that it get relayed through the network. For your experiment, you can actually try with different tx fees to observe the propagation time through the network.

Let me know when your research is over. Curious to see the results :D


How to get coin address balance from *coind server?

You can type 'bitcoind help' to get the available commands. You can also type 'bitcoind help command' to get more information about the command.

You can find your balance in multiple ways:

getbalance: returns the balance of your wallet.dat as a number, you can specify an account (if set) in quotes to get information for a specific account, the default account is '' (blank)

getinfo: returns an array of information about your bitcoind, including balance

listunspent: returns an array unspent outputs sent to addresses in your wallet.dat, you can put an address in quotes to get information for a specific address


Lightning Network: what about tx fragmentation?

A must pay fee like in onchain transaction. So there is no reason to use lightning when A need to pay some coins to different recepients?

Yes, when opening or closing a channel, on-chain transactions occur and thus fees must be paid. However, the interesting thing about the lightning network (LN) is that those two on-chain transactions can now account for a whole bunch of transactions to anyone else connected to the LN. Even further, the closing of a channel can also be the opening of a new channel, so this reduces the onchain payments to ~just one per channel. So rather than having one on-chain fee per transaction, you can pay one on-chain fee for potentially a huge number of transactions.

  I hear lightning can do decentralized exchange. Can someone give an example how it will work with less fees (or zero fee if it possible)?

An exchange service could be built on top of the LN. Such a service could allow users to atomically swap coins that exist in a payment channel, without a custodial service involved. The exchange service simply plays 'matchmaker' for buyers and sellers. A quick google search shows me this service, called SparkSwap, as an example (disclaimer: I have never used SparkSwap, and have no affiliation with them, I literally just found them in a google search and their service seems like a relevant example)

Note that a LN exchange is best suited for trading between LN network and on-chain BTC, or between different cryptocurrencies. Not BTC <-> Fiat $$.

  Another example: if A trade BTC with B,C,D,E.... And A got +0.01BTC for each trade, then B need to pay 0.01 BTC, C pay 0.01BTC..... There is a lot onchain inputs, so a lot of fees (after channel close)

I'm not sure exactly what you mean here, but in general: receiving or sending payments on the LN will not lead to more fees when closing your LN channel. You can open a channel and then send 1 transaction, or send/receive 1000 transactions (within the channel capacity), and the channel closing fee will be the same.


Disclosure: I'm a Software Engineer at BitGo.

You can find a guide for running BitGo Express in the corresponding module directory:

https://github.com/BitGo/BitGoJS/tree/master/modules/express

Please direct further questions to the BitGo support team via email to support@bitgo.com.


Banks don't control Ripple. Ripple is a corporation that is controlled by its stockholders. XRP is a cryptocurrency that trades on a public ledger. If you sell XRP on an exchange, you pay whatever the exchange charges, just like with bitcoin or Ethereum.


In a limit order, you specify how much of the asset (in this case BTC) you want to buy or sell, and the price you want.  If there are matching orders on the book (e.g. someone who wants to sell at the same price, or lower, as the price at which you want to buy), your order will be filled immediately.  If not, your order will stay on the book until matching orders arrive (which could be never).

(It is also possible for a limit order to be only partially filled, if the counterparty wants to trade a smaller amount than you did.  In that case the rest of the order remains on the book.)

In a market order, you only specify how much of the asset you want to trade.  Your order is then filled immediately at the best price currently available on the market.  For instance, if you place a market buy order, you will be matched with the current lowest-priced sell order on the book.  If that order is not large enough to completely fill yours, the next-lowest sell order will be used to fill some more of yours, and so on.


What the maximum number of txout in a transaction?

There is no practical maximum number of outputs in a transaction. The number of transactions can be up to 264-1, or 18446744073709551615. The transaction fee would be more than the total bitcoins to ever exist.


You are likely being scammed again.

The vast majority of bitcoin recovery companies are scams. The ONLY scenarios in which coins are recoverable are if you mistakenly sent them to another address in your wallet (such as an address after the gap limit, sent BTC to an LTC address, ETH to an ETC address, and so on), or if your wallet had a catastrophic derivation issue that resulted in it giving you non-standard addresses which normal wallet software cannot find.

Pretty much anyone else claiming to be able to recover coins that were stolen in scams, hacked from exchange accounts, sent to scammy brokers/investment/mining operations, etc. is also a scammer, trying to capitalize on your loss to extract more funds from you.

Cut your losses now, and do not give these people any more funds.


What RPC can I use to query the balance of an arbitrary address

This has already been answered here:

Calculating address balance
How to get an address's balance with the bitcoin client?

The pull request for this feature (support for watch-only addresses) can be found at: https://github.com/bitcoin/bitcoin/pull/4045


Have a look to https://bitcoin.org/en/developer-guide#term-sighash-anyonecanpay
SIGHASH_ALL|SIGHASH_ANYONECANPAY

Organizer creates transaction with one output and none inputs. Any person can add his funds to this transaction. Once the needed amount is collected the transaction can be sent to a network.

  An organizer sets a goal: an amount of bitcoins must be gathered
  within a specific amount of time

Seems to me that specifying amount of time is not possible

  Random pledgers send an amount within specified boundaries (min/max
  amounts).

Fixed amount.

  If the goal is reached within the specified amount of time, the
  organizer collects the pledges

Let us say "if the goal is reached one time the organizer sends this transaction to a network".

  If the goal is not reached within the specified amount of time, the
  pledges are returned to the pledgers

Any pledger can re-spend his funds at any time before organizer creates valid transaction


In a Proof of Stake (PoS) mining scheme what prevents miners from producing many more blocks or inflating the currency?

There are many different proof of stake schemes, so let's just pick one to talk about. I will be talking about the one that was originally based in Peercoin and is now used by many other coins. And I will be talking about the latest version of that scheme as it evolved during the time from being very much insecure to be little more secure, but still way less secure than proof of work.

So the concept of difficulty remains there. If you mine blocks to fast, difficulty increases and you need more luck to be able to produce next block.

Another important characteristics is that the number of UTXOs does not matter that much. It helps you if you have many of them, but in order to be able to create next block, your chance is proportional to the total sum of the values of those UTXOs. Therefore imagine you have one UTXO with 1000 coins and someone as has 1000 UTXOs with just one coin. Your chance to create next block is the same, assuming we take just one round in isolation.

Only in long term due to other properties of the algorithm, it is slightly better to have many UTXOs. This is because once the UTXO is used to create a block, the new outputs of that transaction are forbidden to participate in block creation for some time.


Can A Mining Farm Profit From Transactions

Fees only get created by the individuals creating the transactions. There is no way for a miner to take a fee from a transaction that did not include a fee. Miners can be selective if they choose to and only include transactions with fees.

Essentially the answer to your question is no they cannot gain any advantage over any other miner. They can select and include transactions with fees but this can be done by all miners.


How does the standard client prioritize transactions?

The priority of a transaction is (the sum of (coin age in blocks * coin value in satoshis) over all the inputs in the transaction) divided by the size of the transaction in bytes.

Here's a random example transaction copied from http://bitcoincharts.com/bitcoin/txlist/:

It has 2 inputs (both of which have since been spent in other (confirmed) transactions rendering this transaction unconfirmable):

one for 0.1005 BTC from block 165774
one for 0.0995 BTC from block 165777

It is 439 bytes long, and has a priority of 432,232,688.

The most recent blocks in the blockchain is 175262 at the time of writing.

I sum the (age * values) for each transaction and divide by size.  The + 1 is because transactions confirmed in the newest block are considered to have an age of 1, not 0:

>>> current_block = 175262
>>> ((current_block - 165774 + 1) * 0.1005e8 +
     (current_block - 165777 + 1) * 0.0995e8) / 439
432232687.92710704

As you can see, the priority of a transaction will go up as new blocks are found.


when will the bitcoin wallet app be available for windows phone?

There is no "the" wallet app.

Various development teams have produced wallet software. Some are only for certain desktop or phone platforms, and some are multiplatform. You can find a list here. Some support Windows Phone.

As you have a Bitcoin Core related tag, there are no plans for creating a version for Windows Phone (nor for any other mobile platform).


Running two bitcoind instances for different nets

Yes, you can. Just be sure to specify different data directories and configure them to use different ports.


Why is pruning not considered already at the moment?

Pruning is being considered, in fact, it was taken into account when designing the 0.8 database format. The unspent transaction outputs (which is the only essential piece of data necessary for validation) are already kept in a separate database, so technically removing old blocks is perfectly possible. It'll likely require some small changes to make sure the code doesn't break when block data that doesn't exist anymore is requested, but this is easy.

The reason it's not implemented is because of the effect on the network as a whole. If a large amount of nodes starts pruning old block data away, it will become harder for new nodes starting up to find the historic data to verify. This is not a problem as such - I expect enough copies will remain that this is not a true problem - but we need a discovery mechanism so nodes don't need to arbitrarily try peers until they happen to reach one that has the blocks they need. In fact, there's a discussion going on on the bitcoin-development mailing list about this right.

EDIT: Pruning was implemented in Bitcoin Core 0.11, and is fully functional since 0.12.


How to calculate the size of multisig transaction?

Let's re-write and calculate from scratch as the calculations that you have posted might not be self-explanatory in itself and some of them are not entirely accurate. From the question, I presume you are trying to find the size of transaction for spending bitcoins from a multi-sig address.

Redeem Script Size

I think there is an error in the size of redeem script that you posted. You need to include the size of OP_DATA as well which comes prior to each public key. It tells the program how many bytes needs to be pushed to the stack. Let's assume we use compressed public keys which are 33 bytes in size. So the total size of redeem_script is 1 + N + 33*N + 1 + 1 = 3+34*N

OP_M: 1 byte
OP_DATA: 1 byte (pub_key length) * N
pub_key: 33 bytes * N
OP_N: 1 byte
OP_CHECKMULTISIG: 1 byte

scriptSig size

I think there is also inaccuracy in the data you posted for this section. ECDSA signatures (including SIGHASH flag) can be 71, 72 or 73 bytes (73 bytes is non-standard as standardness requires low-S value but still flies by consensus). So from a conservative perspective you need to assume 73 bytes for each signature required. Below is the calculation. So you need 1+M+73*M+1+3+34*N = 5 + 74*M + 34*N

nil_length: 1 byte
OP_DATA: 1 byte (len of signature to follow) * M
signature: 73*M
redeem_script_length: 1 byte
redeem_script_size: 3 + 34*N

Input Size Calculation

This section assumes there is only one input that consumes the bitcoins from the multi-sig address. Total input size is 46 + 74*M + 34*N

previous_out_point: 36 bytes
    txid: 32 bytes
    vout_index: 4 bytes
var_int: 1 byte (script_sig length)
script_sig: 5+74*M+34*N bytes
sequence: 4 bytes

Locking Script Size Calculation

P2PKH: 25 bytes
    OP_DUP: 1byte
    OP_HASH160: 1 byte
    OP_DATA (size of scriptPubKey to push): 1 byte
    scriptPubKey: 20 bytes
    OP_EQUALVERIFY: 1 byte
    OP_CHECKSIG: 1 byte

P2SH: 23 bytes
    OP_HASH160: 1 byte
    OP_DATA: 1 byte
    scriptPubKey: 20 byte
    OP_EQUAL: 1 byte

P2WSH: 34 bytes
    - OP_0: 1 byte
    - OP_DATA: 1 byte (witness_script_SHA256 length)
    - witness_script_SHA256: 32 bytes

P2WPKH: 22 bytes
    - OP_0: 1 byte
    - OP_DATA: 1 byte (public_key_HASH160 length)
    - public_key_HASH160: 20 bytes

TX_out_size

value: 8 bytes
len of script: 1 byte
script length: variable as defined in previous section

Total Transaction Size

Let's first calculate the size assuming no SegWit. Then we will look at how SegWit helps in reducing transaction size.

version: 4 bytes
count_tx_in: 1 byte (variable but since we have one input can be represented in 1 byte)
inputsize: 46 +74*M + 34*N
count_tx_out: 1 byte (variable again)
tx_out (assuming one input to P2PKH): 34 bytes
locktime: 4 bytes

So your total size is 90 + 74*M + 34*N. Assuming M=N (as your question dictates) the size is 90+108*N.

Size with SegWit

With the implementation of Segwit, we now count transaction size in weight units and not bytes. Normal transaction size is multiplied by 4 and witness data is multiplied by one. In the previous example our WU will be 360+432*N.

In segwit, we will discount the scriptSig by 4 and add one weight unit that signifies the  number of witness elements. So our transaction size is

traditonal tx: 360 + 432*N WU
- scriptSig: (5 + 108*N)*4 = 20 + 432*N WU
= witness_stripped: = 340 WU
+ number of witness elements: 1WU
+ scriptSig: 5 + 108*N WU
= total: 346 + 108*N WU


How can bitcoin transactions for the same coin belong in different blocks?

Isn't each transaction dependent on a hash of the previous transaction?

Yes and no.

Yes, in that each transaction must be created using valid inputs (ie, referencing a valid UTXO to be consumed as an input). No, in that transactions are not 'dependant' on the previous transaction's hash in the same way that blocks are 'dependant' on the previous block's hash.

For blocks, the hash has an extra level of importance, in that the hash of the block must be a valid proof-of-work on the network. Each block must have a valid hash, and also reference a valid previous block. For transactions, this extra layer of 'valid proof of work' is not required.

(Note that as Ugam mentioned, coinbase transactions are special, in that they do not consumer inputs)

  Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?

When a UTXO is consumed as an input, those coins must be spent entirely, by the creation of new UTXOs as outputs. The sum of the outputs will be slightly less than the sum of the inputs (this difference will become part of the miner's fee for the block), so any excess of coins not specified in a new UTXO will simply be claimed as fees (added to the output of the coinbase transaction).

  Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

Right. A transaction is hashed to obtain the transaction ID (txID / wtxID), but this hash is not subject to the stipulations of being a valid proof-of-work.

There is one situation in which ordering within a block matters: suppose you create a transaction-1 that makes UTXO-1, and then create a transaction-2 that spends UTXO-1 and creates UTXO-2. If you wanted to include both of those transactions in the same block, then transaction-1 would need to be included before transaction-2, otherwise transaction-2 would be seen as invalid (and thus the whole block would become invalid). In this way, 'child transactions' must always come after their parents, if included in the same block.

Otherwise, the transactions included in a block do not have to be related to each other at all, there is no requirement like this. The only stipulation is that a transaction must reference a valid UTXO (and hence the rule about ordering transactions that I mentioned above).


Cryptonote Based Altcoin All Transactions Locked

In Bitcoin block rewards cannot be spent until they have become "mature". This happens once 100 blocks are mined on top of a block. The idea is that new bitcoins should not be spread around while they may still become invalid due to reorganizations.

In Monero the maturity depth is 60 blocks, which is reached after about two hours. I assume that Cryptonote has a similar delay for block rewards to become spendable.


How to broadcast a transaction without using third parties

Yes, it is possible. You need to have a software that can connect to nodes on the network and speak the P2P protocol. That software can then broadcast the transaction by relaying it to multiple nodes who will relay it to their peers and so on and so forth.

One such software is the submittx script writen by Wladimir J. Van Der Laan.


Apart from its main purpose, what is bitcoin network used for?

What are the best examples of such 'other purposes' and projects, especially the ones that are not altcoins?

Things that do proof of existence like OpenTimestamps are not for transfering money but rather committing something (in this case, a hash) to the blockchain so that it is essentially preserved forever.


What makes the block time of a certain coin shorter than the other?

The block time is determined by each coins mining rules. In particular how difficulty is adjusted from time to time. Bitcoin adjusts the difficulty so that the expected time to mine is 10 minutes but a coin can adjust the difficulty to aim for any time.

Aiming for a very high time is inconvenient as users must wait longer to have a transaction included in a block. Using a short time increases the risk of orphans where two miners find the same block at once.


Is it possible to create a unified client that manages multiple cryptocurrencies?

MuCoWa is a multicoin wallet that supports BTC, LTC, DOGE, QRK, FTC, CGA, and DGC. They charge 0.15% fees to send though.


how to develop trading platform for bitcoin

Start by looking at existing trading platforms. Decide what features you want to have. Then think about what data you'll need to store and design a database schema. Then begin writing the code to perform your business logic using the database schema. Last, put a front end on it and invite people to test it.


Does the concept of a blockchain introduce a violation of privacy?

Given this, if you know your friend's public address, wouldn't it be possible to figure out the collective total of their holdings?

I can look at the transactions associated with the address if I know the address which I assume my friend told me.

Isn't that a violation of privacy?

No if my friend told me the address it's not violation of privacy


Why "double spent" can only happen if attacker controls 51% (or more) of the network compute power?

If it's a lottery why is it necessary for an attacker to have more compute power then the rest of the network? Can it have a chance to get ahead of main blockchain generation if it is just lucky?

Yes, a miner could attempt to 'get lucky' and pull of this attack with less than 51% of the hashing power. Keep in mind, if the attack fails, then the miner will have lost money attempting it. 51% is the point at which the miner should succeed on average.

Note: mining is not a lottery by definition, it is only comparable to one in certain ways.


Public key is point on ECDSA curve

Public key + nonce != new public key

And if the above equation works, how can you calculate its private key !

Payment processors accept payment on their addresses, and send funds to users instantly, monthly, or send an equal amount of $ to their bank accounts.

I think you're looking for BIP32 wallets, in which addresses (public key hash) can be derived from other extended public keys (xPubs)


Try to reload your bitcoin node by reinstalling, backup your wallet.dat to be sure you got that safe!

You can just uninstall the wallet without emptieng your data folder first, safes you some downloading. After that delete all files in the data directory except: blocks folder and wallet.dat.

Install bitcoin qt again and make sure you pick the right data directory again. Opening of the wallet will take a while due to checking of the blockchain and building the chainstate.

Probably your error is nog gone.


Do I have to download all blocks to see my bitcoin using bitcoin-qt?

In order for your client to show your bitcoins, you'll at least have to download and process up to the block that validated the transaction with which your money was sent to you. (The client can't show you, what it doesn't know about.)

Bitcoin-QT will allow you to send bitcoins after that, even when it is not synchronized completely yet. Since likely your funds have only been sent to you in the near past, you will have to download almost the complete chain to reach that stage.


There are some examples in the bitcoinj library itself which are always up to date (as they are part of the build).

The command line tool 'WalletTool' that Mike wrote is pretty useful for the basics of wallet creation, sending, receiving etc.


What is the benchmark that mining ASICs are measured with to determine the hash rates?

When a mining ASIC claims to run at 1 MH/s or 10MH/s or even 1000 GH/s, at what difficulty

10 MHash/s means that the chip can do 10 million hashes per second, regardless of what the difficulty is. The difficulty changes how many blocks you find, but it doesn't change how many hashes the chip performs.

  and with what algorithm is that measured against?

It'll usually say what algorithms it's capable of mining, but if it doesn't, you can usually assume it's SHA256. There are a couple of odd ducks, like hybrid ASICs that can mine multiple algorithms at once; those are actually two different mining circuits put on the same chip.

  cgminer shows the ASIC running at the hash rate claimed. But when mining in a pool, the pool shows a hash rate of roughly 1/3 what cgminer says.

There are three possible explanations:

The chip is lying about how many hashes it's doing, but the pool can't be cheated in this manner, because it relies on shares. (unlikely)
You're failing to submit otherwise valid shares, because of some software misconfiguration. (slightly more likely)
You've been unluckly, and have gotten less shares than average. This will even out over time. (most likely)


Seized items that are not of obvious benefit to the thief eventually get sold at public auction. If they fall into a process that doesn't understand the technology or there are auctioneer agreements then it will be a traditional auction. Value is not likely to be understated or undersold as this will be a very marketable item to advertise.

Stolen goods are also used to attempt interdiction. The government would use the coins in sting operations and in attempts to undermine confidence.


Missing transaction in newly installed Bither wallet

Updated 2020-04-29

  It turns out to be an issue in TLS version of the windows desktop version. We've released a new version of Bither Desktop to resolve this. Head over to bither.net to download the latest version and it will be all fixed.

I'm the developer of Bither. Sorry for the late response.

No need to worry about your money and Bither is not a scam. Bitcoin.org has a restricted review process to list wallets on it. We can never get access to your private keys, thus your bitcoins are safe in Bither.

Bither is a decentralized SPV wallet. It needs to connect to other bitcoin nodes and sync block data to get all your transaction history. But in some network conditions it would be too hard to connect to any nodes. Bither relies on background processing to help you keep up with the blockchain tip. But mobile devices often have limit on background running time.

In your case, I think you are not syncing to the latest blockchain data. Though I'm not sure what caused this, but there is an easy way to fix it.

Update to the latest version, open Bither, swap to the right page, click Advanced Options -> Reload Transaction Data. This will download all your transaction history from 3rd party block explorers. And then you should be able to see your bitcoins. Like @Murch mentioned earlier, you can use Network Monitor to see if you are catching up with the blockchain tip and what's going on.

If you have any further questions, feel free to contact our support crew listed on the website. support@bither.net.


If port 8333 is closed, will a node relay transactions to its peers?

Yes it will, connection directionality will not affect block and transaction relaying.


Currently atmoic swaps aren't really done except in really special occasions and with specially crafted transactions. There aren't really services that offer atomic swaps and existing software cannot perform atomic swaps without special modifications.

There is currently ongoing work on creating actually usable and easy to use atomic swap software. Most of this is working through the Lightning Network and HTLCs.


As of the 0.8.x series, the reference client does not support paper wallets. You can export individual keys, and print them to paper, but you are very likely to shoot yourself in the foot unless you're familiar with the implementation details.

In particular, change (the difference in value between coins used to create your transaction, and the amount being sent) is sent to a fresh address in order to increase privacy of the system. When you're using a paper wallet, you will likely miss these, as well as key pool entries.

There is support planned for deterministic wallets (BIP32), which means a single backup of a wallet seed will be enough to create the wallet. This may or may not end up in 0.9, though.

The reason why no "Export wallet to PDF" exists, is exactly because in the current model, this would result in many misconceptions and lost coins. Without deterministic key generation, no immutable dump of the wallet can survive (a series of) spends.


Handling "dead" (double-spent) transactions in my mempool

A will be kicked out of the mempool when that block is received, and getrawtransaction will subsequently fail for it.


Troubleshooting pybitcointools transaction signing/verification

OK, I figured it out.

It was an issue with the value of v in vrs (v being the version byte, and r/s being the DER values). Since v is not encoded by DER signatures, the check for 27 <= v <= 34 was failing because not knowing the v value would sometimes require v be equal to None, 0 or 1.


How can I perform key derivation from a 130 characters hex public key?

With only a public key, you cannot do BIP 32 derivation. BIP 32 derivation requires an additional piece of information called the chain code. This chain code is derived with each key, so each private-public keypair has its own unique chain code. Without the chain code, you cannot do any further BIP 32 derivation.


have can i retrive my bcc (bitcoin cash) from bitcoin address?

Depends. Do you control the adress you sent the bitcoin to? If so, simply import the private key in a wallet compatible with bitcoin cash.

If you don't, you're dependant on bittrex, and they only recover amounts higher as 5000$, with a 10% fee i think.

https://support.bittrex.com/hc/en-us/articles/115000961172-Bittrex-s-Crosschain-Recovery-Policy


How to prevent ASIC mining for my new altcoin?

Are there any steps which I should include in my altcoin's mining algorithm to prevent ASIC mining?

That's not really what you should be asking. You should be asking, "Can someone design an ASIC which is more effective at mining my altcoin than a general purpose CPU?" At sufficient scale, that is always possible.

However, you don't really care if someone can invest $1 trillion and get an ASIC that is 1% better than a CPU. If your attacker had that much money, they'd crush you no matter what. You care whether they can invest a reasonable amount of money and create something significantly more efficient. (Either in power consumption per hash, or capital cost per hash.)

Also, you want some other properties:

It must be reasonably fast to verify. (But doing so can weaken the algorithm, see Why did Litecoin choose the scrypt factors that they did? for an example.)
Switching chain tips must not cause a miner to lose a lot of progress. (Otherwise, miners have an incentive to ignore new blocks if they almost have a block of their own.)
Someone who modifies the block header must have to redo all of the work. (Otherwise, mining provides no protection.)
Mining speed must scale linearly with computing resources. In other words, you shouldn't be able to double the number of computers you have and quadruple your mining speed.

I don't know of an algorithm that satisfies these five properties, but the problem hasn't been proven impossible.

  What about EquiHash Algorithm?

Look at these two criticisms of EquiHash:

http://www.openwall.com/articles/Zcash-Equihash-Analysis
https://petertodd.org/2016/cypherpunk-desert-bus-zcash-trusted-setup-ceremony#equihash-proof-of-work

There are probably algorithmic improvements still available in EquiHash, and there is almost certainly a hardware speedup available.

(There is also an unverified claim that someone has created an FPGA Equihash miner.)

  Do I need to implement a completely new algorithm for mining?

You're unlikely to do much better than the attempts above.


Do the channel balances get publicly announced in real-time on Lightning Network?

Channels do not publicly announce their balance for several obvious reasons

It would be a huge privacy concern if balances could be viewed
live on the network. People could monitor large parts of the network and
aggregate data about how balances change over time, which could then
be used to trace payments through the network and deanonymize users.
If every transaction by every node required a broadcast of the new
channel balance, then bandwidth usage would become extremely large.
The network would not scale for the same reasons Bitcoin can't have
massive blocks. It would make running a node impossible on a
commodity computer and internet connection.
Broadcasting channel balance would really be quite useless because
the concept of "real-time" does not exist in a distributed network. A
node could advertize its channel balances to its peers, but before
any peer has chance to act on that data, those balances could have
changed if they route a payment for another peer. The system is in
constant change, and there is no way to atomically check a channel
balance and then send a payment over that channel. It would be a bad
idea to attempt to add such locks because there is no central
coordinator of them, and it would result in all kinds of race
conditions happening, like livelocks and deadlocks.

Channels only advertize their capacities, features, fees, minimum and maximum (optional) transaction values. There is no guarantee that a payment will route successfully even if you've provided a valid amount between the minimum and maximum with the correct fees.


If someone knows my bitcoin address, does this mean they can spend it or move it?

No. An address is designed to be given out so that people can send you money. You cannot spend Bitcoin by knowing an address, otherwise block explorers wouldn't be showing people's addresses. What is needed to spend Bitcoin are private keys. Those need to be kept secret and are never given out to anyone. One private key corresponds to one address.


Stop bitcoin-qt from retrying transaction

Yes, Bitcoin Core will try resending the transaction until it confirms or is replaced. You can make it forget the transaction by starting Bitcoin Core with the option

-zapwallettxes=<mode>

Then, be sure to use the inputs in another transaction, because the transaction is still valid and might yet be confirmed. The only way to invalidate it is by doublespending the coins.

The easiest way to make sure that you have invalidated the old transaction is by moving your wallet's complete balance to a new address.


How do I move a client/wallet to a different machine?

Copy the wallet.dat onto another machine, put it in the appropriate folder and either sync your Bitcoin from the Genesis Block with the network, or run it with -rescan option.


Channel funding (and the distribution of funds) is determined at the time of channel opening. Once opened, a party cannot ‘add funds’ to the channel, this would require opening a new channel.

If you opened the channel and did not specify that some number of sats should be pushed to the remote node at the time of opening, then the channel will open with the entirety of the balance on your side. Note that pushing sats to the remote node is equivalent to making a payment to the remote node.

If you send a payment using the channel you opened, you will gain an ~equivalent amount of incoming capacity.

The current BOLT spec does not include multi-party funding, but this feature is planned for future updates to the spec.


What is a UTX 0 Proof? (as discussed in this video)

UTXO is short for "Unspent Transaction Output". You can imagine the UTXO set as a set of tuples of the form (txid, index). Transactions remove items from that list by claiming the outputs and add new items by allocating the bitcoins from claimed outputs to new outputs. Basically the whole of Bitcoin boils down to agreeing on what the current UTXO looks like, as it tells you how many bitcoins are owned by each address at any time.

The UTXO Proof Peter was talking about is a way for a node, that does not store an entire copy of the UTXO set, namely a DHT node, to validate transactions. This is done by querying other nodes in the DHT and retrieving the parts of the UTXO that is needed in order to validate the transaction.

Notice that, while there are some ideas on how to implement this, there currently is no prototype.


What if a pair of double-spent transactions are collected into a new block?

When Alice sends the bitcoin, she spends an Unspent Transaction Output (UTXO) created by a previous transaction. To create a doublespend, she has to use the same UTXO as an input for another transaction.

As every full node keeps track of all existing UTXO, it is trivial for all nodes to recognize these transactions as doublespend. A block containing two conflicting transactions would be invalid, and thus would not be accepted by any nodes.


How much do nodes get from blocks, including fees?

1) Fees are very block-dependent but recently have normally been in the 0.25 - 0.5BTC range

2) A mined block currently gives 25BTC + fees.  From the above, fees are coming in around 1-2% of the total block reward


0 Payout at litecoin pool with a processing power of 1.6 Mh/s. Why?

According to the crypto-coins' profitability calculator coinwarz, with that much hash power you could have a gross daily earning of about US $14 should you mine Dogecoins and not Litecoins. Mining Litecoins instead, theoretically you could earn about US $11 per day.

Most of the times it's much more profitable to mine an alt-coin than the grand-daddies of them all (i.e. Bitecoin and Litecoin). The problem is, of course, you need to have wallets for those alt-coins and open an account at an exchange that accepts them to get bitcoins or dollars for them.

How many blocks per day is your pool finding? You won't be paid at all until/unless your pool finds a block.  That statistic will give you an idea of how often you'd be paid.

In "normal" pools the whole blocks' reward goes to the pool administrator who then pays miners their share -according to the hash power they've provided- minus his fee, so there's a bag of coins (coming from fees) whence to pay you should the pool find no blocks in some time.

Since p2pools lack (by design) a central administrator, you're forced to wait until it finds a block. The pro is you don't have to trust an admin. to be fair and honest, only source code you can audit/inspect should you know how to.


Do I wait or do I have to do something about it?

do I just wait and the BTC will comeback

No, the transaction be13...5f1b is complete and 0.00361861 BTC (about EUR 18.86 at time of writing) has been sent to address 1Exq...qoPf

Nothing is going to come back just by waiting

The transaction, like all confirmed Bitcoin transactions, is final and irreversible.

  should I do something so it isn´t floating around?

It isn't floating around. It has been moved to address 1Exq...qoPf. It can be spent by whoever has the private-keys from which that address was derived.

  I payed/sent an amount and it failed somehow

This is an issue with whatever software/website is showing the "failed" message - you should ask the owner of that website (or developer of that software).


What is the easiest way to programmatically obtain the current USD-BTC spot price?

You could use the JSON encoded ticker data available from MtGox at: https://mtgox.com/api/0/data/ticker.php

Just use whatever your language's equivalent to cURL or wGet is and parse as appropriate.


Sweeping funds from addresses generated by Extended Private Key (BIP39)

I know Bitcoin has this concept of "sweeping" funds. Does that still involve incurring a flat fee for every address generated by the master private key?

No, sweeping an address involves inputting a private key into some wallet software, and then having the wallet software initiate a tx to empty that address’ funds entirely into a new address that the wallet controls the private keys for.

While a BIP39 xpriv key can be used to derive many child keypairs, the xpriv cannot itself be used to spend the UTXOs of those child addresses. You need the private key of each address in order to spend it’s funds. The network has no way of knowing how a key pair was derived, so only the private key of each individual address can spend its funds.

For best efficiency, you’ll want to batch all of the UTXOs into a single transaction with a single output (or maybe more than one, depending on how you want to divide and store the funds).

A single tx with a lot of inputs will have a higher fee than any single tx, but it will be lower than the total fees paid if you send each one individually.

I’m not familiar with blockcypher, but in general if a tx is sent on the network, and then you’d like to spend those funds again, a network fee will be incurred. So I’m not sure their service will save you money in the way you’re looking for.

Lightning network is a potential solution for payment processing with lower fees, but the network is still young so it will take a little time for adoption to happen.


Calling importaddress will rescan the whole blockchain in default according to bitcoin.org

  Set rescan parameter to false to not rescan the block database
  (rescanning can be performed at any time by restarting Bitcoin Core
  with the -rescan command-line argument). Rescanning may take several
  minutes.

  help importaddress

  importaddress "address" ( "label" rescan p2sh )

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

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

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

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

  Examples:

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

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

UPDATE Since Bitcoin core v0.14 you can use importmulti to import addresses.

bitcoin-cli importmulti '
  [
    {
      "scriptPubKey" : { "address": "1NL9w5fP9kX2D9ToNZPxaiwFJCngNYEYJo" },
      "timestamp" : "0",
      "label" : "Personal",
      "watchonly": true
    },
    {
      "scriptPubKey" : "76a9149e857da0a5b397559c78c98c9d3f7f655d19c68688ac",
      "timestamp" : 1493912405,
      "label" : "TestFailure"
    }
  ]' '{ "rescan": true }'

Response:

 [
{
  "success": true
},
{
  "success": false,
  "error": {
  "code": -8,
  "message": "Internal must be set for hex scriptPubKey"
  }
}
]

Note:

Bech32 addresses are not supported using this method until the moment. (You're free to edit this answer when it's available.)
importmulti will not speed up importing progress since this method locks your wallet and block any further RPC calls.


if you want to use bitcoin core, you have to install blockchain. maybe you can use prune mode after its totally synced.

If you want to use JSON-RPC without installing the blockchain, I suggest you use electrum servers. You can send JSON-RPC commands without installing anything. You just connect to someone's server.

the commands not the same as bitcoin-core, for instance, you can't createrawtransaction but you can get any address balance or transaction details.

if you want to work with bitcoin-cash, You can connect to electrum bitcoin-cash servers.

check electrum protocol methods here.


How to send bitcoins from selected address on blockchain.info wallet?

The Blockchain.info's My Wallet "Quick Send" feature just selects one of your addresses that has a sufficient balance to fulfil your payment. If none has, it will combine multiple to fulfil the payment amount.

How Blockchain.info choses the address is not specified. My best guess is that it will try the oldest output first. Keep in mind that it is not possible to always send from the same address since you will most probably receive your bitcoins on multiple addresses.

If you want to specify from what address to send, you can use the "Custom" option. It will let you configure your transaction from input addresses to change addresses. It also supports multiple output addresses.


How to get bitcoin Unconfirmed Transactions

You can use blockcypher api to check bitcoin address transaction.

http://api.blockcypher.com/v1/btc/main/addrs/{{YOUR_ADDRESS}}

For ex :
http://api.blockcypher.com/v1/btc/main/addrs/1DEP8i3QJCsomS4BSMY2RpU1upv62aGvhD


How do can I create a bitcoin wallet with a already created address and private key?

Bitcoin Core supports importing private keys. Use the importprivkey RPC.


How to Curl into Bitcoin node with Swift?

8333 is the node connection port. Since you didn't change the RPC port in the config file, the port you should connect to is 8332.


What are the usability limitations of Core?

Are there any others?

No support from mnemonic recovery phrases, also known as seed phrases or backup phrases.


How does Bitcoin Core sort memory pool transactions by fee?

The excerpt you're showing is for the priority area in blocks. The concept of "priority" in the source code corresponds modified bitcoin-days-destroyed per kilobyte. It is only used for a small portion of the block size (max 50kB by default in Bitcoin Core 0.11.x, and max 0kB by default in 0.12.x, it can be changed with a configuration setting).

Look at the rest of CreateNewBlock, which uses sorting by feerate, by iterating an index on the mempool that is pre-sorted by feerate (=satoshi per kB).


How to calculate the checksum of an extended public key?

it seems like the process to calculate a checksum for an extended key is to decode the base58 string to data,

If raw_xpub = version + depth + fingerprint + child + chain + DATA
than to make the checksum you need to do doublehash of xpriv/xpub (sha256), in python:

hashed_xpub = hashlib.sha256(raw_xpub).digest()
hashed_xpub = hashlib.sha256(hashed_xpub).digest()

and then take the checksum as first 4 characters (0 to 3) and add it at the end of the raw xpub:

raw_xpub += hashed_xpub[:4]

Finally, run it through Base58 to encode it. I think you've might performed base58 operation too early based on your question. It's the last step in the process.


Can the 51% attack be made to become 81% attack or 91% attack?

The 51 percent attack isn't necessarily "faking the data". It is generally referred to say including a double spend in a block that would normally be rejected by the network but the honest part of the network struggles to reject that block and the chain built on top of it because it has a minority of hashpower. The point being that proof of work is still completed, it isn't "faked". But in answer to your question, of course a 81 percent attack or 91 percent attack would be even more concerning than a 51 percent attack. It is called 51 percent because that is the minimum needed to pull off the attack.
There is nothing that can be done to increase the minimum of 51 percent needed to pull off the attack to say 81 percent in a proof of work context, it is the nature of the system. Of course, in reality the network may choose to follow the chain with reduced proof of work but without the double spend transaction in it. It would be disruptive, extremely expensive for the attacker and could (likely) fail.


What happens if I buy Bitcoins and the price goes down?

If you bought a bar of gold at $1200 / ounce, then the price of the gold drops to $600 / ounce, you wouldn't actually lose any money at all unless you decided to sell your gold at that time.  However, if you wait until the price of gold rises to $1800 / ounce, then sell it, you will gain money.  The key is an ounce of gold is still an ounce of gold, regardless of the "price" in some other currency.

Same goes for bitcoin, or indeed any currency.  If you trade it at one price, then subsequently trade it at a different price, you'll either gain or lose money.


How exactly can I generate a transaction id?

The serialized format is described here.


If I have bitcoins in blockchain.info wallet, can I transfer it to my local bitcoin account wallet?

Yes. Get a Bitcoin address from the wallet you want to send to and then send to that address.


Largest current merchants accepting Bitcoin?

The Bitcoin wiki contains a rather large list of companies that accept Bitcons. You can also add yourself to it once you started accepting Bitcoins.

The truth is Bitcoin is still in it's early days; soon it will be much easier to accept them.


The UTXO database starts empty and then is updated while the blockchain is parsed in the manner that you described. Only, there can be more than one input and more than one output for a transaction, so I'd put it like this:

for block in blocks:
    for transaction in block:
        for(input in transaction):
            utxoset.remove(input)
        for(output in transaction):
            utxoset.add(output)

Obviously, the block is checked for validity and therefore we know that the inputs and outputs are legit.

The UTXO set then stores the UTXOs referenced by outpoints as key, where an outpoint consists of:

TXID: Unique hash identifier of the transaction that created the output
index: the position of the output in the transaction's output list

And the information stored in the Transaction Outputs is:

value: number of satoshis the output is good for
pubkey script: the conditions the output can be spent under

Finally, for each block undo data is generated, in the case that a reorganization occurs.


Can a blockchain transaction history be updated by text messages using a mobile network?

No, at present this is not possible. The Bitcoin network runs only over the internet. (Of course, there are lots of mobile data networks in the world, and Bitcoin works just fine over those.)

One could imagine some kind of service to receive transactions by phone or text and relay them to the Bitcoin network (and perhaps vice versa), but I don't think such a service currently exists.  I'm not sure that very many people would find it useful.

What applications do you have in mind for such a feature?


Timer-based consensus algorithm in blockchain

Keeping block time at 10 minutes is only one of the many benefits that PoW provides. Other important ones include preventing double spending and transaction censorship. Most of the PoW alternative consensus mechanisms out there simply fail to ensure this level of security. There is an interesting conversation on the Bitcoin mailing list that dives into Proof-of-Stake and its inefficiencies in ensuring the above.

Double Spending: PoW ensures that a node has spent electricity and compute power in order to find a hash that matches the current target. This ensures that there is a cost involved in case any one wants to 'rewind' the blocks and make a separate transaction that double spends the previous one. This would also mean, that the person who wants to double spend would need to amass more hash power (and hence investment) than rest of the network combined, an almost impossible feat.

Transaction censorship: In cases where you do not have PoW, an attacker will bootstrap millions of nodes to ensure that he is the one that gets chosen to form the block. In that scenario, he can ensure that certain transactions do not enter the blockchain, aka censorship. Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction does get into the blockchain from the efforts of another block producer. This is trivial under proof-of-work, and is ensured by asking people to make huge investment to get the hash power needed to mine block. Since it is non-trivial to acquire energy PoW prevents censorship attacks.


Is it normal for ABE to get "out of sync" whilst re-creating it's blockchain?

I am pretty sure I can answer my own question here... the output is literally the total number of blocks, and the total number of transactions witnessed by ABE posted side by side.

Everything seems to be running smoothly. The number of transactions is increasing almost exponentially now by the number of blocks.


What is a cost-efficient, fast and easy method of transferring btc between own computers?

[Edit: Read comment as to why this is not a good idea.]

You could just store the wallet.dat file on both computers, which contains your entire wallet. Then both computers will be able to spend from the same wallet.

Do make sure to copy the wallet to the other computer from time to time: if you don't synchronize regularly, the balances might start mismatching because the private keys are no longer the same.


nmat: i think you got the signs wrong in there somewhere. the fees will /decrease/ your effective selling price, and /increase/ your effective purchase price. so it should in fact be:

ExchangeA_sell * (1 - ExchangeA_fee) - ExchangeB_buy * (1 + ExchangeB_fee)

and also, you should take into account any deposit/withdrawal fees (E.g., when you withdraw via LR from mtgox, that's a 2% hit, when you use dwolla, that's 0.25USD fee, etc) that you'd incur when moving money between the exchanges.


Unplugged Trezor when incoming transaction was unconfirmed

If the transaction has confirmed, then there is nothing that you need to do. Your Trezor device does not actually receive the transaction nor does it need to. All that matters is that the wallet software that you are using knows about the transaction, and if the transaction has confirmed, it is trivial for it to find out about the transaction. Check the wallet software that you are using and make sure that you see the transaction there.


Tax implications of withdraw fee from one exchange (Binance) to another GDAX/Coinbase

Grain of salt disclaimer:(Consult a professional, lawyer, accountant, doctor as I'm a computer engineer, musician, and painter I'm clearly none of those.)

Also read this https://www.irs.gov/instructions/i8949 if you need to fill out 8949.

I hope this is a clear explanation of how capital gains taxes work in general.

Here's an example of what I would do normally assuming a FIFO tax treatment:

You need to pay tax on your capital gains but you want to subtract your cost basis from the total value you sold for as the basis is not taxed as a gain. (Note that if you can't prove the cost basis I believe the entire sale of 0.49 at 400 would be considered taxable)

{sold value - cost basis = capital gain} that you need to pay tax on (income tax if under 12 months, 15% if it's a long term gain)

First find the cost basis.
(0.2*100)+(0.3*120)=20+36=$56 (this is your cost basis)

(I'm going to round your 0.49 eth up to 0.50 as a clear example with round numbers)

Then compute the amount generated from the sale (I'm calling this a sold value)
0.5*400= $200 (this is your sold value in my example equation)

Now find the capital gain using the equation below:
sold value - cost basis = capital gain
200-56=$144

For long term gains over 12 months it's 15% * your gain minus the cost basis

144*0.15=$21.50 due in taxes.

For short term gain (held under 12 months, as is your case) the gain is considered income.

144*your tax rate = what you owe to the IRS as this was a capital gain. This gets added to your AGI so if you have an AGI of 200,000 your AGI is now 200,144 and the 144 gets taxed as ordinary income.

Regards


I encountered Signature is found in scriptCode exception when trying to make a BTC transfer

The referenced outputs are P2PK
createOutputScript(fromAddress) implies P2PKH
P2PKH scriptSig doesn't match with P2PK pubkeyscript

Resources used to write this three-line answer:

Compile Core
Use 30 GB bandwidth to download the blockchain
Two-three hours of time

but I'm happy to help more if this isn't enough.


How can one embed custom data in block headers?

When you generate a block, the generation transaction (the one that creates new coins) has an attribute called coinbase. It's a special value you can put anything you want in to make the block unpredictable to others (and this is good).

So, naturally, you can put text in this attribute, although most just put mining-related information that is not human-readable (nonce and extra-nonce).

You can read this coinbase by using a patched bitcoin node that can dump blocks, for example with the "dumpblock" or "getblockbyhash" patches.

Or you can just print every string in the blockchain database directly :
strings -n 20 blk0001.dat

Example for the 1st block:

Coinbase: 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

ASCII-translation:
ᝣᝣᝣᝣᝣᝣᝣEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This is what is used by the Eligius pool ; it puts prayers in this field.


Reliable, efficient way to parse the blockchain into a SQL database

I created a fork of blockparser with a 'csvdump' command that will generate a details dump of the blockchain in CSV format.  There are also some support scripts in that repository for creation, population and periodic update of a PostgreSQL database.

Be aware that the resultant database is pretty large; you might want to consider PostgreSQL over SQLite for this one.


The number that generates the private key, is it stored somewhere?

The private key IS a number, and is remembered as such. It may be generated thought various means (like HD wallets, deterministic generation, from a BIP39 seed, or randomly). It is usually stored as 32-byte array.

The private key is then converted to a public key. This requires a complex mathematical operation, and results in a coordinate pair on an elliptic curve. This is usually stored as a 33-byte or 65-byte array.

That public key is then hashed, a checksum is appended to it, and converted to base58. The result is what is called an address, and is what you give out to others to get paid by them.

The private key never leaves your computer/wallet/app. The address is public.


What is this extra address on blockchain.info?

This is because you did not have a coin that exactly matched the amount you wanted to send to your friend.  So bitcoin had to split a larger coin into 2 coins... 1 with the amount to send to your friend and the rest as "change" to send back to you.  The address you don't recognize is a new address that was created for the change, and it's in your wallet.


What is the Coin Base Text of a bitcoin block?

Every block has one coinbase transaction, which is a transaction that miners use to send the block reward and fees to one or more outputs.

Since that transaction is generating new coins it has a special kind of input, that is called the coinbase, which allows up to 100 bytes of arbitrary data to be written to the blockchain. Most mining pools will put some sort of text in that field to identify themselves as the miner of that block. A solo miner can put anything* they want in that field, such as the message that Satoshi Nakamoto put in the Genesis Block coinbase:

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

*As of block 227,836, the first few bytes of the coinbase must contain the block height


Is this even possible?

Yes.

In General
You can move wallet contents from almost any Bitcoin wallet software to any other Bitcoin wallet software that supports the same standards. For example, if the first wallet supports Bech32, you will need the second wallet to also support Bech32.
There are only a couple of small pieces of data that need to be copied into the new wallet and exactly how you do this depends on the specific wallet software used. We should remember that just because something is possible doesn't always mean it is easy.
The general process is to transfer the private keys. In the case of HD wallets, you can effectively do this by one of several methods, including:

Using a seed-phrase (also known as recovery-phrase or backup-phrase) that conforms to a known standard (BIP39, Electrum, etc).
Using the master private key, typically in wallet import format (WIF)

You also need to specify the derivation path as this determines which  Bitcoin addresses had been created by the first wallet from the master private key.

Specifics
If we look at the specific wallet you mentioned, Blue wallet allows you to import wallet contents from a variety of other software and allows you to specify a key in WIF format.
To extract a master private key from Wasabi you may need to resort to tools like https://github.com/lontivero/ExtractXPrivWasabi (untested, no idea if it is safe, best to inspect source, build from source, run on computer without ethernet or WiFi  etc, isolated from any network)


I had a similar problem - it turned out that Bitcoin was running out of memory. (This happened when I was using one of DigitalOcean's 512MB VPS's.)

Here's what you can do to check if this is the problem:

Run the command watch free -m

You'll see something like this:

             total       used       free     shared    buffers     cached
Mem:           997        891        106          0        117        640
-/+ buffers/cache:        133        864
Swap:         4095          0       4095

Look at the intersection of -/+ buffers/cache and free. This is how much free memory you have. In this example, it's 864 MB.
If that number drops below 10 MB before the crash, that's probably the issue.

Here's what you can do if this is the problem you're having:

Get a larger VPS from your provider.
Enable swap
Try adding

dbcache=50
maxconnections=4
rpcthreads=2

to your bitcoin.conf file.


Is there a way to run bitcoind without being a full node?

You might not want to run bitcoind at all then, you could just use a client-only node (AKA thin client) tool such as bitcoinj.

Before going for a thin client approach, make sure you understand the differences from running a full node and also some security concerns.


Why is a 20 byte hash acceptable in p2wpkh but p2wsh needs 32 bytes?

As per this post by Gregory Maxwell, HASH160 provides enough security for the trivial case of public key hash based addresses, whereas script hash addresses can benefit from the additional protection against collisions provided by a longer hash.

The rest of the thread covers more details of the benefits of moving to sha256.


How to find out addressHeader p2shHeader

These are address prefixes: A value prepended to a pubKey hash or scriptHash before base58 encoding. Assuming they are bitcoin forks and share similar source code, you can find them in the source code (eg. Dogecoin):

chainparams.cpp Line #128

I haven't seen a list of altcoin address prefixes, but I can see how that might be useful.


You need to increase the max file upload size of your node using the nxt.maxUploadFileSize property in nxt.properties.

For example, set:

nxt.maxUploadFileSize=10000000

To set the limit to 10MB


Change currencies through BitCoin or other Cryptocurrency

With no bank account: You can buy Bitcoin in your home country then sell them for cash in person in the US through sites like Local Bitcoins once you get to the states.

With large sums of money its good practice to wait for six blocks on the blockchain before considering the transaction confirmed.

With a bank account: Non-U.S. citizens are allowed to open a bank account in the United States. You can wait to open a bank account in person when you arrive or try opening a bank account in your home country at a bank that operates in both your home county and the US. (In Brazil HSBC is one example of a bank that operates in both counties).

To sell your Bitcoins get an account at an exchange like Coinbase or Circle, trade your Bitcoins for USD there and connect that with your US functional bank account to withdraw the funds.


Why does Ripple needs to have a long ledger?

First note that Ripple uses the term ledger slightly differently than general use.

In Ripple a ledger is the set of all Ripple accounts, all their current balances, all open trade offers, and only the transaction details that justify the changes in this ledger from the previous ledger. A specific Ripple ledger does not contain any other past history of transactions.

Even so, a Ripple ledger can still be somewhat large due to implementation details of it's binary representation. The implementation values lookup speed, syncing efficiency, hashing of sub-parts, and other features over absolute size.

Transaction history in Ripple is stored by servers keeping multiple past ledgers, as many as desired, that form a chain similar to Bitcoin's block chain. However, unlike Bitcoin, it's possible for new transactions to be processed by a Ripple server that only has the last validated ledger. Such servers (validators) are free to discard all older ledgers (and their transactions).

Currently most public facing Ripple servers (that accept transaction submissions and state queries) maintain a near fully history of all past ledgers and can therefore answer queries relating to historical information (e.g. a list of past transactions that effected a specific account via the account_tx API), but there is no requirement for any given Ripple server to make such history available (servers inform clients of the range or ledgers they have available).

It's desirable to have at least a few Ripple servers making as much past history as possible publicly available so that anyone interested can query information about past transactions. For example, it is expected that gateways will run Ripple servers for their customers and would configure at least some of those to store the full history since the gateway's inception (at least).

As the storage requirements for full history increase it may become more common to have "slim" Ripple servers that only store a fixed history (perhaps a few weeks worth) for cost reasons. Ripple clients could use these for faster day-to-day operation (for example if their were more of these or if they were located closer to the client) and only need to query the potentially slower (for example if they're fewer and more overloaded or farther away from the client) servers when more ancient history is required.


This looks like a subtle issue with the code you are using and I do not think you are taking a sensible approach to getting the name back from the input. The javascript will not execute inside of your PHP, it only runs when sent to the browser.

When it executes your function prompt is called but the return is everything inside the quotes on line 7, which is not what you typed into the input but is exactly what is inside the quotes:

$answer = "<script type='text/javascript'> document.write(answer); </script>";

I should ask, in what mode are you executing or calling your PHP - PHP can be executed standalone or it can execute with a browser page request.

I would solve this in a very rudimentary fashion by creating a HTML form which only displays if some $POST option is not set with the input, setting up the form to post back to the same URL and checking first for the $POST data as said. Then, if the $POST data is set, go ahead and create the output page - all in the one PHP file.


Import / create a Wallet from a key with bitcoind or bitcoin-cli to use as a hotwallet?

You can use the importprivkey and importmulti RPC calls in bitcoin-cli to do this.


The blockchain does not contain yet-to-be-published transactions to publish them based on conditions.  The blockchain is the structure that transactions are published to.  There is no such thing as a "pre-loaded transaction" that can be "released".  Either A (Alice) or B (Bob) has to publish it.

What Alice can do is give Bob a pre-signed transaction that spends an output from a transaction from Bob that has not been published yet.  This way, when Bob publishes his transaction, he can now publish the pre-signed transaction from Alice, but can't publish it beforehand.  This requires more coordination that I believe you are looking for, but it's possible.  It would go like this:

Bob creates a transaction, B1, with an output to Alice, but does not sign nor publish it.
Bob sends Alice B1, still unsigned.
Alice uses the output on B1 as an input on her own transaction, A1.  This transaction has an output that pays to Bob.
Alice signs A1, but can't publish it because it spends the still unpublished B1.  Instead, she sends the signed A1 to Bob.
Alice can now go offline, as her part is complete.
Bob, now in possession of a signed A1, signs and publishes B1 to the network.
With B1 now published, A1 is now a valid transaction, and Bob publishes it as well.

Again, I don't think this is exactly what you are looking for, but I don't think what you are looking for is possible.  Smart contracts generally require sending transactions back and forth before publishing to the blockchain.  You really can't have a smart contract with someone with whom you've never communicated.  The up-front communication is the contract part, and publishing to the blockchain is more like resolving the contract.


Framework for designing Blockchain (in combination with secure multi-party computation)

You may find hyperledger fabric useful for your purposes : Hyperledger Fabric


Is it possible to use the same BIP39 list of seed words to create addresses for different crypto assets?

BIP 43/44 gives each coin a unique derivation root. Many wallets use this, including some multi-currency wallets.

Be careful when using multiple wallets with the same mnemonic though; the least secure wallet can cause you to lose all your coins, even coins that this wallet doesn't support.


Wouldn't this mean that every time a new transaction is added to the block (before its mined), that all nonces previously attempted need to be tried yet again?

Yes, but "need" is a bit too strong of a word in this context.  Because you can't predict the outcome of a hash without performing the hash, each new hash attempt is just as likely to meet the target as the previous one.  As such, yes, it is possible that a nonce that has already been attempted will now succeed given that the merkle root has changed...but it is no more likely than the nonce you were about to attempt before adding the new transaction.  There's no real reason to re-try nonces.  The odds aren't any better.

  Wouldn't this discourage miners from adding transactions to the block if they have to hash everything with nonces again?

No.  Because the odds do not change, there is no negative incentive to adding a new transaction.  However, transactions come with miner fees, so the positive incentive is still in place.

  Also, is it possible that no nonces could produce a valid successful/winning hash?

Yes, it is possible, although not probable.  Remember that a successful hash is one that is less than the target.  These means there are quite a large number of nonces that will be successful, however, as a set they represent a very small proportion of the total possible nonces.  Even if hypothetically there is a block header that is "unmineable", a competing block would not be.  A block will still be found, and it will likely have a very similar set of transactions in it.


You can use Blockchain Explorer and just search for your address either the source address from the Trezor HW Wallet or the destination one, the paper wallet's address.
You will be able to view the whole transaction and the balance in both addresses.
Note that transactions take some time to be included in a block 10-20 minutes, the bigger your transaction fee the faster your transaction will be included in a block.


How can I calculate the breakeven price for buying and reselling on cryptocurrency exchange?

There are two issues with your calculation:

You are assuming that you are both a Maker and Taker (either maker when buying and Taker when selling, or taker on the buy and maker on the sell) which could be true, but might not always be the case
You are calculating both fees based on the Buy Price (which is not accurate because the corresponding maker/taker fee is a percentage of the selling price too).

Your calculation only makes sense if you are being charged both maker- and  taker-fees and your buyPrice == sellPrice. Which will never be 0 because if you are buying and selling at the same price then you lose out on the fees.

If both orders were maker orders your calculation would be:
Break Even would be when: (sellPrice * (1 + maker)) - (buyPrice * (1 + maker)) = 0

If the buy was a maker order and the sell a taker order:
Break Even would be when: (sellPrice * (1 + taker)) - (buyPrice * (1 + maker)) = 0

You would need to extend these scenarios for all 4 possible permutations of the maker/taker fees.


How is the hash target set and verified by all nodes?

The difficulty adjustment algorithm is as follows (from the source code):

unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{
    if (params.fPowNoRetargeting)
        return pindexLast->nBits;

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
    if (nActualTimespan < params.nPowTargetTimespan/4)
        nActualTimespan = params.nPowTargetTimespan/4;
    if (nActualTimespan > params.nPowTargetTimespan*4)
        nActualTimespan = params.nPowTargetTimespan*4;

    // Retarget
    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
    arith_uint256 bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= params.nPowTargetTimespan;

    if (bnNew > bnPowLimit)
        bnNew = bnPowLimit;

    return bnNew.GetCompact();
}

The adjustment is only run every 2016 block. What it does is it takes the timestamp of the block at the beginning of the last period (2016 blocks prior) and the timestamp of the block that came before the one with the adjusted difficulty. Those timestamps are then used to calculate the amount of time that passed between the first block in the interval and the last block in the interval. Then that timespan is clamped to be at least 1 quarter of the target timespan and at most 4 times the target timespan. To calculate the new difficulty for this interval, that target is multiplied by the actual amount of time that passed, and divided by the targeted amount of time.

Since all nodes are calculating the target at the same block and with the same previous data, the target calculation is deterministic and everyone will land on the same target.


Is there a way I can get my own independent vanilla p2p cli wallet?

There are no recommendations in this answer, but there's some terminology that will help you with your further research:—

You want a wallet that doesn't require you to surrender your private keys to some third party. Ideally, a widely used wallet for which the source code is published for anyone to audit (i.e. open source), so that there are no hidden security defects.

Such a wallet will eliminate counterparty risk (i.e. the risk that a third party, knowing your private keys, spends all of your bitcoins). However, it will only marginally improve your privacy because all Bitcoin addresses and transactions are visible on the public ledger — Bitcoin is pseudoanonymous. The one slight disadvantage is that you have to make your own secure backups since there's no third party doing this for you. Some wallets let you make a paper backup by writing down a seed phrase — but don't let anyone find the piece of paper, and be sure to have a contingency plan in case of fire.

An SPV wallet allows you to construct transactions without having to download the entire ledger, but an SPV wallet connects to someone else's copy of the ledger, so you would have to decide for yourself if that's an acceptable compromise. After you've constructed a transaction, you can sign it (with your private key) without requiring a copy of the Bitcoin ledger — this is how you spend bitcoins from cold storage.


Enter your Bitcoin address (the one you were paid into) into a public blockchain browser such as https://blockchain.info/. That will show you the relevant entries in the global shared Bitcoin ledger, which confirms that you, as the holder of the private key for that address, are the owner of those funds.

If you lose control of your private key for any reason, then your bitcoins might not be yours for much longer.