If hardware wallet provider disappears, can I still manage my coins?

I understand these wallets only work with provider's mobile app, online interface or their computer software, correct ?

No. Some of the most popular hardware wallets are supported by third party software. For example, Trezors and Ledgers can be used with Electrum who have implemented support for these devices directly. Other wallet software like Wasabi Wallet and BTCPayServer support these devices through the Hardware Wallet Interface project which is also a third party project.
Other hardware wallets like the Coldcard don't have a vendor provided app at all and require you to use these third party software too.

All transactions go trough their online service one way or another, correct ?

Only if you use the vendor provided app. If you use a third party software, transactions will be broadcast in the manner which that software usually broadcasts transactions.

What will happen if their service simply goes offline ? Mobile app unavailable, etc ?

You will be required to use a third party software. The device itself will still function, but the vendor provided wallet will no longer be available. This does mean that there will not be any future firmware updates, but existing firmware on the device will function without the vendor having any online service.
In fact, most hardware wallets have open source firmware (even those with closed source chips like Ledger still provide a binary blob in their open source stuff) so others can make their own firmware even if the company stops supporting the hardware.

Am I able to see/export my private keys/coins so they could be use/spent by other means even IF the application or online service is unavailable and I only have my hardware wallet ?

Yes. When you setup the hardware wallet, it should have prompted you to write down a seed. This seed is usually a BIP 39 seed. This seed is used to generate all of your private keys. You can import this seed into any wallet that supports BIP 39 and be able to access your coins without the hardware wallet. However if you lose this seed, there is nothing you can do as private keys cannot be exported from a device (besides a few attacks and vulnerabilities where you can, but generally you aren't supposed to be able to do that).

Considering all the above concerns, doesn't that make the hardware wallet equally secure as a mobile app wallet ?

No, hardware wallets are more secure than a mobile app wallet. Hardware wallets don't rely on the vendor being online and still in business. Hardware wallets also aren't connected to the internet, they are intentionally a separate device so that any malware (mobile devices can get malware too) cannot retrieve the private keys. Even if a hardware wallet required the use of the vendor software, I would still consider it safer than a mobile wallet, although I would recommend that you choose a different hardware wallet to buy.


Consider using Bitcoin but just heard the IRS is sending tax notices to 10k plus users

Bitcoin doesn't use RSA and there is no encryption or cryptography that hides transaction details. Bitcoin is pseudonymous, not anonymous. There are unique identifers for every participant in Bitcoin, the somewhat hard part is tying those identifiers to actual people. So there is no RSA, number theory, or ECC involved in what the IRS is doing because none of that is involved in the details they are concerned about.

What observers like the IRS can do is follow transactions and see how money changes hands from some identifers to others. Some identifiers may be known, such as exchanges and other large services. Most are not and likely to be individuals. Using various software tools, you can try to work out how money is changing hands, but it is error prone, can have a lot of false positives, and is actively being counteracted with things like CoinJoins.

But the IRS probably isn't following those transactions. They are doing something much easier: subpoena the exchanges for customer information. By law, exchanges need to gather identifying information about their customers. This includes things like Social Security Number, passport numbers, driver's license numbers, etc. They have to store all of these personally identifying information and they are all tied to user accounts. Additionally, all of these user accounts have trade and transaction history tied to them as well.

So the IRS is basically just asking (or compelling) exchanges to hand over all of this information about their users and comparing the numbers that were filed in their tax returns to the numbers that they calculate based upon the trade and transaction data that they have gotten from the exchanges. No cryptography, machine learning, or even programming involved whatsoever.


The very basic idea of an FPGA is that it can be loaded with a specific firmware (a layout of logical gates, in essence). That page contains the firmware you'd need to load onto a Xilinx FPGA (A Spartan 6) in order to use it as a mining device. ZTEX refers to a suite of the FPGA, and various IO controllers (USB, etc.).

Roughly speaking, the steps you'd need to follow would be:

Buy device
Plug in device to your computer
Load firmware onto device from your computer
Run a piece of software on your computer that interfaces with the firmware now loaded on the FPGA
Profit (in a couple years)

To answer your questions: yes, the device would need to be plugged in to a computer using the method in your link, and yes, you can "chain" them - i.e. have more than one plugged in. I've greatly oversimplified steps 3 & 4, by the way.


What exactly is Microsoft 365 going to support?

Presumably, this means that if you type '0.5 BTC' into a cell, it will be recognized as an amount of money instead of text. (Currently, if you type '$5' into a cell, it will recognize this as an amount of money.) You will probably be able to write formulas that manipulate Bitcoin amounts, which could be useful if you wanted to sum all of the Bitcoin amounts in a column.


In the case the difficulty increases as much in future, will the possible hashes run out/be insecure?

As I understood, in the block hash, the amount of zero's is the nonce,

No, that is incorrect.

The nonce is a value in the block header, which is then hashed. By changing the nonce, a new block header is effectively created which has its own unique hash.

  Then the hash is recomputed for each value until a hash containing the required number of zero bits is found.

No. Contrary to popular belief, the correct hash is not based on the number of zeros in the block hash. That is just an abstraction to make it easier for people to understand.

What the correct hash actually uses is a target value. This target value is a 256 bit integer. In order for a block hash to be considered having a valid proof of work, it, when interpreted as a 256 bit integer must be less than or equal to the target value.

Since it is actually an integer comparison and not checking the number of 0 bits, there are far more possible target values.


No, the transaction fee is not increasing over time. According to the Bitcoin wiki, these are the rules under which the reference implementation decides weather or not to include transactions (and therefore how fast they are confirmed):

  27.000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.
  Then transactions that pay a fee of at least 0.0001 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 250,000 bytes big.
  The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

The priority addressed in the bold part is calculated like this:

  priority = sum(input_value_in_base_units * input_age)/size_in_bytes

As you can see, the priority increases with the age of the coins. Thus, the "older a bitcoin gets"* the more likely it is that the transaction is included in a block, even if no fee is paid, in fact.

This behavior has the following advantage: That way you have the option to pay more fees to get your transaction confirmed faster, or less and even nothing if you can wait a day or two.

Regarding the second part of your question: Yes, when a miner generates a block he gets the transaction fee of each transaction in this block.

* to be exact: "the older the last transaction spending the coins is"

When buying bitcoins with fiat, exchange portals like MtGox or Bitstamp usually charge another fee (about 0.5% on both bitcoins and fiat), which does not go to a miner but to the exchange portal. It has nothing to do with Bitcoin fundamentally, so it's totally up to the exchange how to calculate this fee. However, I don't know of any exchange which considers the age of the bitcoins, and I can't see any reason why they should.


Solution

  "bitcore" is dead, regardless. It's not Bitcoin Core, to ease
  confusion.


What are the relevant hardware-mining options as of 13 May, and and how should one choose one over another?

In order of hashrate:

ASIC >> FPGA > GPU >> CPU

">" meaning "more powerful", while ">>" stays for "completely outclasses".

Currently there are some ASICs out there, but not so many to totally destroy the chances for the other devices to mine anything, so there's still some people mining with FPGAs and some with GPUs.

Of course those using FPGAs and GPUs already have them, and it would be a pretty bizarre business decision to start using one of them right now (might make some kind of sense for the resell value: an ASIC's only purpose is mining bitcoins, while the other devices once obsolete might be used for something else).

Officially there are three ASIC manufacturers:

Avalon: first to complete an ASIC, ships big devices, but currently isn't taking new orders.
Butterfly Labs: vapourware! Started collecting money almost one year ago, and constantly misleads his customers stating they are going to be "ready in two weeks". Recently shipped a few devices to some selected members (journalists, etc.) and they were very inferior to their specifications.
ASICMINER: instead of focusing on selling hardware, they produce their own devices and use them, selling you shares in their company, giving you dividends; recently they also started accepting orders for small USB ASIC miner.


Electrum does not support QR code scanning on Mac OSX as stated on download page:

  Note: The QR code scanner is not supported in OSX binaries

There has been several related bugs, but as of v3.2.2 the issue has not been resolved by anyone.  Some related discussion and attempts to debug.


How has the hash rate for bitcoin continued to increase despite price drops and miners dropping out?

the hash rate for bitcoin tripled from around 15 EH/s to 45 EH/s. Why is this the case?

Well, at the simplest level, that means more hashing power is being used to secure the network.

This could mean that a larger number of ASIC units are running, and/or that more efficient ASIC units are being created and used. A more efficient ASIC would perform more hashes per second, for a lower cost per hash per second.

Every miner will have their own costs, motivations, etc, so it’s hard to speak broadly about ‘what miners will do if price is x and the hashrate is y’. For example, a price drop means some miners with the highest costs may no longer be able to operate profitably, but perhaps those miners are ideologically driven, and will take a loss with the hope that the bitcoin they mine will one day be worth more than it is at that time. Etc.


Recovering bitcoins after the owner's death

There are two main ways someone can hold Bitcoin

On an Exchange or Online Wallet

or

Privately on a computer in a wallet or offline private wallet

For (1) you will need to obtain the username and password to access the account.

For (2) you will need to login to the computer and, depending on your luck, if the wallet is not encrypted, you should have access. If the wallet is encrypted you will need the password to transfer/spend the coins.  If you do get access to the computer then look for the bitcoin application and run that to see if there are any BTC in the account.

If your brother had a paper wallet then you will need to find this information as it will have public and private keys to access the coins. These can be imported into a wallet to give access to the funds.

Unfortunately, if you cannot find the info above the coins are lost. There is no central control of this currency so there's nobody you can contact for help.


Just add amount parameter to QR data:

bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?amount=0.005

use google chart to generate QR

https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?&amount=0.005

  if you are asking about auto sending bitcoin through QR so it's not possible.


zcoin seems to be a fork of Bitcoin Core.

Bitcoin Core's -salvagewallet does carefully try to recover a broken wallet database (wallet.dat file).

What it does is:

Copy the wallet.dat file (wallet.<date>.bak)
Tries to recover only the private keys

Make sure you check your debug.log after -salvagewallet wallet operation.
Look for lines starting with "Salvage" to get more information.


What explanations are there for the bubble of 2013 and subsequent Bitcoin price in 2014?

BTC is a speculative commodity so bubbles are to be expected, and bubbles are cyclical in nature. The previous bubble went up to about US$250 and took several months to build back up and then inflect to climb exponentially to ~1200. There's not one reason for this, and it happens with other bubbles too. But I'll try my best:

The general explanation is that smart money buys low, generates media attention that induces FOMO (fear of missing out) which attracts buyers, who raise the price to new highs, increasing media coverage ad absurdum, when finally there are not enough suckers to keep the rate up and people panic and start selling. Then there's usually a "dead cat bounce" (you'll see the price jumped back up after the first plunge from the peak) followed by more selling. The smart money sells all the way to the top, and buys all the way to the bottom. Now they have to start the cycle again, so they use their market making power to quiet things down and make it feel safe again, waiting for a new crop of people to come back, buy, see amazing returns, tell their friends and media, and the bubble starts again. We're likely there now.

The China factor One main factor leading up to the ~1200 bubble in particular which made it so much higher was the rapid expansion of BTC speculation in China at the time. That's simply a huge market, and New Chinese exchanges were opening up on an almost weekly basis, with relatively low barriers to investment. You could see them leading the price action at the time, and growing their capitalization at a crazy rate. Exchanges like BTCChina and Huobi etc. overtook MtGox's volume in a matter of weeks if not days.

Post-burst Volatility I'm sure there are plenty of reasons for this, one of which is just the general nature of bubbles as explained above. However there were at least a couple of specific things I can think of that contributed to volatility post the ~1200 bubble: Wall Street, media coverage, and the sorry state of exchanges at the time.

Wall Street around that time started giving quants some money to play in the BTC market. You could literally see the bot action taking over MtGox on the way to the top and then back down again. I'm not saying the bots did it, but they do make more money when price movements are wide, and had enough influence on the price to induce these large moves. For example they would create lots of bids at a certain low price with one hand, and begin selling to apply downward price pressure with the other. People would put their bids just in front of the bid wall, thinking it represents a solid price support (a "bottom" for the move). As selling accelerated, the bid wall started receding lower, so they could keep selling into those suckers' bids. Then the wall was removed completely, creating even more panic selling, until the smart money decided it's time to pump the price back up. This, and the opposite ("pump and dump") were happening on a regular basis and observed live by traders on forums like TradingView.

Media coverage was a giant piece of uninformed hype. The price action drew attention, but the stories were more absurd than the price. When some company said they'd accept BTC the price jumped. Then someone talked about taxing Bitcoin and the price tanked. Most stories were non-news or rumors or actual fake stories planted by smart money, but panicky noob traders would buy and sell on it as if it were news about GE or Microsoft, reported in the WSJ.

Finally, Exchanges were constantly beind DDoSed and manipulated, which made small-time traders panic and sell, and then panic and buy back in when the price jolted back up. Once the largest exchange by volume, MtGox exploded in slow motion, causing many ripples along the way (mostly in the weeks following the ~1200 peak). Exchanges would frequently go illiquid and disappear with your money. Exchanges were so badly run they would constantly make you feel like your orders aren't being processed and induce panic. This adds volatility.

I'm sure there's plenty I'm missing, happy to see more comments/answers!


sendrawtransaction without downloading blockchain

The RPC call sendrawtransaction tries to broadcast the raw transaction you give it by first adding it to its own mempool of transactions. If you don't have the UTXO database, then you won't be able to validate the inputs of the transaction, so your node will reject it from its mempool. So, essentially, no, there isn't a way with the default client.

You could modify your client to have a new RPC call that just sends the raw transactions without checking it. But then you run the risk of broadcasting an invalid transaction and having your peers increase your ban score.

Also see: Pushing tx to the network via AJAX, without installing bitcoin. That question lists a few APIs that have support for broadcasting a raw transaction, which may be helpful to you.


Suggestion for Airgap Bitcoin Core - Comments?

If I understand you correctly, Im not sure your system will work, because your air-gapped laptop is never connected to the internet, the transaction wont get broadcast.  You can try it, I may be wrong.

I have done a similar process using rawtransactions, where you prepare the rawtransaction on an online computer, using an explorer API (https://chainz.cryptoid.info/api.dws is one that I found works) you get the tx input and vin, create the rawtransaction and save the hex output to a small USB (smaller the better).  Then on your airgapped machine use signrawtransaction to sign it, then transfer that hex output back to the online machine and sendrawtransaction.

I automated that process in Python, you can see how it works in more detail on my github https://github.com/Scalextrix/coinofflinewallet

It worked with QR codes as well for a fully airgapped solution, but I had a lot of trouble with the Python webcam/QRcode libraries and ended up not bothering.  My code is not extensively tested, its really an example, you should validate it fully before use.


How does a Bitcoin (Core) wallet use inputs?

Bitcoin Core uses a Branch and Bound algorithm to search for an input set that exactly matches the send request. To that end, it will deterministically search the combination space of all of its available utxos and pick the set that is the most efficient if there are multiple solutions. The Branch and Bound algorithm is briefly described in the sourcecode and more comprehensively in my master's thesis.

If no matching solution is found with the Branch and Bound algorithm, Bitcoin Core will fall back to its previous strategy. This entails sorting all unspents descendingly by their value and iteratively picking a subset by randomly including or skipping list elements.


creating a fork of bitcoin, how to modify core to create my own network

Regtest should really suffice for your basic testing. If you really want to modify chainparams, you would first start with the DNS seed data in the file; these are hard coded.


How do I throttle mining in Phoenix 2.0 to keep my cards cooler?

You cannot tweak phoenix to keep your cards cool.

Using stock software like the AMD Catlyst Center you can adjust you settings the way you like them and save it as a preset. Make sure to save the preset in the start menu.

You will make two pre-sets.

Maximum Speed - Clock speeds set to maximum and fan way up
Silence! - Clocks at minum and fan set as low as possible

You can then copy the shortcuts to you desktop and double clicking them will apply the pre-sets. Or you can run them using windows scheduler or some remote scripts or triggers.

You just need to find the sweet spots.
for example: 1 x AIT 6990 with stock cooler and OC Switch on (tested 45 minute intervals)

max - 880clock, +2% power and 72% fan = 75ish celcius @ 770mh(stable)
min - 500clock, +0% and 38% fan = 75ish celciu stable temp @ 450mh


Is bitcoin actually some sort of private key?

Really there are no bitcoins, just transactions. A transaction will have outputs of specific amounts, and if you have the key to spend a certain output but haven't spent it yet, it is known as your unspent transaction output (UTXO), and the amount of all your UTXOs is known as your balance. The private key is what allows you to spend a transaction output, it provides the proof you own it. And you don't send your private key when you make a new transaction, you simply sign a new transaction with your key to spend the UTXO you 'own', and create new outputs owned by the recipient, usually by assigning the outputs of the new transaction to their public key / bitcoin address.

The miners are also given bitcoins through special transactions known as coinbase transactions, which don't have inputs because they are creating brand new coins, but still have outputs to be spent by the miner.


What is the transaction rate bottle neck?

I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...

A block can hold no more than 1 MB of transactions. This sets the network's transaction speed limit.

A block is generated once every 10 minutes on average. We can calculate the block chain's write speed with:

w = s * g

where w is write speed MB/hour, s is block size limit in megabytes (1 MB/block), and g is the rate of block generation per hour (6 blocks/hour).

Plugging in the value yields:

w = 1 MB/block * 6 blocks/hour = 6 MB/hour

Converting to bytes/second, that's:

6 MB/hour * (1 hour/60 minutes) * (1 minute/60 seconds) * (1,000,000 bytes/1 MB) = 1,700 bytes/second

In other words, think of the blockchain as a hard drive. We can write to this hard drive at a rate of 1,700 bytes/second.

Even if we develop faster computers, we can't write data faster than this because the network rejects any block larger than 1 MB. We need to make some allowances for SegWit, but for now, let's keep things simple.

A one-input, one-output Alice-Pays-Bob transaction requires ~ 200 bytes. This is the absolute best case. We can, therefore, obtain an upper bound on the transaction rate using:

v = w / z

where v is the maximum transaction volume, w is the write speed calculated above (1,700 bytes/second), and z is the average size of a transaction (200 bytes/transaction).

Plugging in the numbers:

v = 1,700 bytes/second * (1 transaction / 200 bytes) = 8 transactions/second

  The answer to my question should be something like verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.

The network might appear to have a limit based on hardware or validation, but it does not. At least not directly.

As to why we should limit the block chain's write speed in the first place, the answer has to do with network security. Increasing write speed means:

data flows through the network at a higher rate;
more data must be stored by every node;
more transactions must be validated by every node.

Every node sends and receives every block, and every block must be stored. Increasing the blockchain write speed means that every node pays the price. Some won't be able to keep up, regardless of write speed.

Transaction validation is a resource hog due to signature validation and UTXO set manipulation. Storage space and bandwidth are also considerations, but less resource-intensive than validation.

Now, if you're asking why we have a 1 MB limit given XXX computer has such-and-such technical capabilities, that's the realm of the Never Ending Debate. Calculations have been done and simulations have been reported. They are not hard to find. They are, however, hard to believe given their wildly-differing claims and underlying assumptions.

The best thing I can recommend is to download a copy of Bitcoin Core 0.16.0 and try syncing a node from scratch. Report back when you're done.

The write speed limit we see is a compromise between inclusivity (more people using bitcoin) and security (difficulty of double-spending attacks). The limit may not have been set correctly, but figuring out where (or even how) to set it is exceedingly difficult. Not because of lack of ideas, but because of too many and lack of widely-accepted selection criteria.


You can trade with a neighbor that also installed both wallets ;) or use one of the exchanges... The bigger volume the better:
https://coinmarketcap.com/currencies/iota/#markets


Why has this blockchain transaction not confirmed?

It depends on a (currently) unconfirmed input: https://blockchain.info/tx-index/106830375/1

There is also a warning on this input (previous output) that it is a double spend, probably due to the ongoing malleability attack.

Warning! this transaction is a double spend. You should be extremely careful when trusting any transactions to/from this sender


Comparing UTXO transactions with Accounts transactions

The only thing which Ethereum community or other altcoins community does better is marketing. I won't even consider it better or sometimes consider scammers or frauds or people trying to spread misinformation. I have never seen such hatred and misinformation being spread in any industry about something like Bitcoin which is the biggest reason why all this exists.

There are few related questions that have highlighted the difference in UTXO and accounts in past:
UTXO model vs. account/balance model
Why is there "Change" in Bitcoins?

https://cryptofees.info/ uses CoinMetrics according to the footer of website. Coinmetrics has mentioned in a post that you cannot compare transactions of UTXO chains with Accounts based chains:

The third column is txCount. That refers to the number of transactions happening on the public blockchain a day. Be aware that for low-fee blockchains, it’s really easy to fabricate a whole bunch of transactions. So this isn’t necessarily that reliable! Additionally, UTXO networks like Bitcoin can batch a whole bunch of transactions into one, so txCount underestimates those ones. You have to therefore be careful comparing the number of transactions on Ethereum with Bitcoin; by its very nature, Bitcoin typically has more transactions than that datapoint suggests. Naively comparing the UTXO to account based systems by transaction count is like watching motorway traffic and comparing the number of buses versus motorcycles to guess at how many people are making trips. Maybe there are the same number of buses and motorcycles – but each bus might have 50 people inside of it.

https://coinmetrics.io/on-data-and-certainty/
Mean transaction fee for Bitcoin and Ethereum according to Coinmetrics:

Outputs per day in Bitcoin:

https://bitcoinvisuals.com/chain-output-count-day
You can also check: https://transactionfee.info/charts/payments-per-day/ (The payments metric counts the number of outputs a transaction has and subtracts one to exclude the change output. If a transaction has only one output, then it’s counted as one payment. The purpose of this metric is to provide a more accurate representation of real economic activity on the Bitcoin network.)

There are lot of other differences and its difficult to compare but things that one should consider while responding to marketing trolls:
Bitcoin doesn't have failed transactions involving any fees: Do we have failed transactions in bitcoin?
Blocksize and Transaction Size (the answers are not updated and gas limit has increased): https://ethereum.stackexchange.com/questions/1106/is-there-a-limit-for-transaction-size/
Bitcoin has max 1.5-2MB of block per 10 minutes on an average
Bitcoin transactions and size: https://twitter.com/murchandamus/status/1262062602298916865

You need smart contracts for batching in Ethereum according to below links:

https://ethereum.stackexchange.com/a/71271/
https://ethereum.stackexchange.com/a/84064/
Lets consider if Bitcoin had no batching and I had to somehow send BTC to multiple people:
3f99102c76af2ecfe7c7da826cbefd8a5d4465ac2c63e88a975df89b23c8bf5d has 1 input and 5 outputs
Size for each input and output involved in tx
   Input: 91 vB

   Output 1: 32 B
   Output 2: 32B
   Output 3: 32 B
   Output 4: 31 B
   Output 5: 32 B

   Size of original tx: 344 / 235 bytes
   Virtual size / weight: 263 / 1049

   Fee for original tx: 0.00019 BTC
If you create 5 transactions to use one input and different outputs mentioned in above tweet, 91*4=360vB extra will be required or maybe more.
If same fee rate is used (73 sat/vB), 0.00026 BTC extra fee will have to paid
SO YOU PAY DOUBLE FEE FOR DOING THE SAME THING and 5x transactions!
One of the reasons batching is used by lot of people in Bitcoin: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

Bitcoin has few layer 2 solutions that are used and thousands of on-chain transactions have moved to off-chain. I couldn't find a website that could show approximate transactions and not even sure if its possible to do it for LN, but below links have related information:
http://bitcoinkpis.com/layer2
https://bitcoin.clarkmoody.com/dashboard/
https://1ml.com/statistics


This isn't really possible, short of brute force.
An address contains no information about how it was derived, if it relates to any mnemonic at all, or whether it followed a standard path system.
Absolutely nothing prevents you from deriving a p2pkh address using a segwit derivation path.
Many wallets do have mechanisms to try various derivation paths up to the wallet's gap limit for the selected address type, but searching for a specific address is a fool's errand unless you already know it belongs to a certain mnemonic, and have some vague idea of what derivation path it would fall under (or a lot of patience to try several billion combinations). In those scenarios, you'd usually be better suites to writing your own script to do it under the constraints specific to your case.


Transaction doesn't show up in my Blockchain wallet

target your transaction on this site. Also review this


EstimateSmartFee returning same amount, regardless of conf_target

This is expected behavior, especially on testnet. The fee estimator will often return the same fee rate estimate for confirmation targets after a certain value because there isn't enough or any data about transactions confirming at those confirmation targets. So it falls back to the highest confirmation target that it can estimate for and uses that for confirmation targets than that.

Also, you are on testnet which does not really have a fee market, and whatever fees it may have are probably bogus. Thus any fee estimates are also bogus.


It is a left over API design from bare multisig transactions.

The example you provided is a P2SH multisig - in this, the actual output script has no way of telling Bitcoin Core that it is a multisig output. It can be any script. Thus, Bitcoin Core just decodes it to a regular P2SH address.

Although no longer commonly used, there are also bare multisig outputs, which use multisig scripts that are not wrapped in a P2SH. These would be of the form M <pub1> <pub2> ... <pubN> N OP_CHECKMULTISIG for a M-of-N multisig (this is the redeem script for a P2SH multisig).

When Bitcoin Core used to decode these, you'd get one address per public key, hence the array.


is it possible to get mempool transactions as hex using bitcoin-core?

Bitcoin core doesn't support batch requests

Yes it does. Bitcoin Core uses the follows the JSON-RPC Specification for batching requests. Just use that with a custom client of your choice to interact with the RPC server to get that information. python-bitcoinrpc makes this easy to do.


Trying to run bitcoind gives Segmentation Fault

This sounds like an issue for the GitHub issue tracker, not stack exchange :)

https://github.com/bitcoin/bitcoin/issues

Please include the core dump, and which version of bitcoin you built.


What happens if the power goes out during bitcoin mining process and system shuts off?

The wallet will be safe. (Unless your drive becomes corrupt and you have no backup of the wallet anywhere else)

Nothing happens to the BTC you already have.

The Blockchain will be out of sync until you sync it again.

If you were about to find the block, it will be lost and the reward will not be awarded.


If you have no record of the private key stored the funds are lost forever, or more correctly you just can never spend them again. As you never had the private key stored on a hard drive, there's not anything you can do to recover it.


listtransactions via RPC returns false in PHP

According to documentation, there are several optional parameters you can provide  in order to retrieve list of transactions for account(s).

Function:

listtransactions [account] [count=10] [skip=0] [include_watch_only]

[account] (string) leave "" for default account and "*" for all accounts, default ""
[count] (int) number of recent tx to return, default is 10
[skip] (int) number of recent tx not to return, default is 0
[include_watch_only] (bool) include watch-only addresses, default is false

I suggest to try the call with all 4 parameters:

$bitcoin->listtransactions("*", 10, 0, false);

I am not PHP expert but the output you get might be indication of missing parameters.


671d52454812a73517aac8b8d0aeff82a81dc1a493f84fdcfa6273e930fa6288 is the txid while 0c47b3981a84eed8032fe87f7909da1c95fb35adcb8ba533c24712589487ca49 is the wtxid. wtxid was introduced with segwit. For more info check BIP141


Does bitcoin improve on "hard" currencies in any way?

There are huge differences between FIAT and Bitcoin.

Fiat is created out of thin air "with fractional reserve banking" and other mechanisms, there is no stop on how many will be created.

Another problem is that every country is FORCED to create more of it.
Since otherwise the value of their money would increase to much, ending all export industry and tourism in that country.

So when the US prints an extreme amounts of FIAT they know that China must follow, which means that Japan must follow and the US must print more, and so it goes on.

Bitcoin can not be created out of thin air, and it takes an ever increasing energy cost to create one.

And since no country base their economy on it, its free from having to be endlessly printed. (It can´t even if it would be.)

Another very important difference is that Bitcoin is the only digital money you can own yourself with no one else having any access, and thus keep on your own computer or in your own cellphone or store on a USB the key to your money.

All other digital money, is money that is stuck in a bank and thus they might play around with it and go bankrupt.

But a Bitcoin is a Bitcoin and not simply a promise in their system.
This also means that you can send them any time of the day instantly to anyone you like now even on Facebook or in emails.

The limited amount also gives it a longterm backing in that if it picks up in any market, it cant stay this low and will have to go much much higher, a value of something like $50-$5000 would not be strange in 10-20 years IMO.


Explainations about chaining of transactions

I don't fully understand your question, first a reaction on your assumption.

It is indeed so that your wallet does not hold actual coins. However, consider the distinction between the terms wallet and client. This is not an official distinction, but it is useful to understand the two different principles.

A Bitcoin client, stores the complete block chain. When you request information about an address or a transaction, it can inspect the block chain and retrieve the requested information. So indeed balances are retrieves by a query to the block chain. Most clients keep an index of all transaction of your addresses so that these queries can be achieved very efficiently.

A wallet often refers to the set of private keys of your own addresses. For the default Bitcoin client, this is the wallet.dat file. It contains a list of the addresses you own and the corresponding private keys you need to make transactions with your addresses.

However the term wallet is also often used for a Bitcoin client, f.e. on the Bitcoin homepage. A caveat here is that some of those wallet indeed do not store the complete block chain but have other techniques to implicitly query the block chain in another way. This sort of clients are called lightweight clients.

Now, what a transaction is, in principle, is just a handing over the control over a certain value in the block chain to another address.

For each address there are zero or more transactions that have the address as output. When you did not send them over to someone else, the are called unspent bitcoins or unspent transaction outputs. The sum of those make up the balance of the address.

When you want to send these coins, or a part of them (note that there is no notion of a coin, but just some value of currency that you send which can be any decimal number up to satoshi precision), you make a transaction in which you claim some of the unspent outputs for your address (as inputs for your transaction) and distribute the value they have over other addresses (which are the outputs for your transaction). So the unspent outputs for an address can be used as inputs for a transaction.

When you sign the transaction and it gets verified in a block, the unspent outputs are now spent and new unspent outputs have been assigned to the addresses you specified in the transaction outputs for the transaction.


When new nodes (with empty ledger) entered to block chain, how they can check the correctness of the transaction, if their ledger is empty ?

It cannot. It must sync the entire blockchain first.

  How new nodes get synchronized with the block chain (get the list of the blocks, and all the history of the transactions ) ?

A new node will connect to other nodes in the Bitcoin network. It does this through the peer discovery mechanism which uses DNS seeders and seed nodes to find nodes to connect to. From there it requests from its peers the blockchain and is thus able to download the entire blockchain. Of course the new node will also fully verify all blocks and transactions in what it receives to ensure that the data is correct and valid.


Bitcoin Halving - What is it? How is it calculated? Does it affect my bitcoin balance?

The halving takes place approximately every 4 years. It is programmed in the software.

It will not affect your current bitcoins at all. It only affects the newly mined bitcoins which will be 12.5 after the halving (instead of 25).

The halving is expected to influence the price of bitcoin. With less supply the price will probably rise given that demand is the same... at least in the long run, since supply could also stay the same or even increase if people that were holding bitcoins start to sell.


Is the transaction database ever shortened?

Meni's answer is probably correct, but describes a very far future, in my opinion.

In the more near future, I believe we'll see fully-validating nodes that do not keep the entire block chain around. The current reference client implementation uses blockchain + transaction database for validation, which cannot easily support pruning. I'm working on modifying the validation code to use a separate database of just the unspent outputs instead, which is much more efficient and only requires a few hundred MB of storage, in addition to the blocks it wants to keep around.

I'm sure this will open possibilities, but somewhat further ahead, I believe this will lead to a separation between validation nodes and archive nodes. The former relay and can be queried for their memory pool, and check whether transactions are valid, but they cannot serve old transactions or blocks, and hence cannot be used to bootstrap a new node from. For these purposes, one will connect to an archive node (this could be via the P2P protocol, but may as well be HTTP or BitTorrent).

Disclaimer: these are my views/opinions, and may not reflect those of other (core) developers.


Bitcoin Signatures are susceptible to quantum attacks - how exactly and with what practical impact?

Which precise parameters of bitcoins blockchain would be susceptible
  to quantum attacks?

(1) Private Key: ECDSA is the first thing that can get vulnerable with quantum computer. Using Shor’s algorithm and Grover’s algorithm you can break the private and public key encryption. As Peter said in the previous post, hashing is Quantum resistant, so you would not make your private key vulnerable in post quantum world when providing an address. However, when a person sends you some bitcoins, his signature/public key can reveal the private key. The owner of the quantum computer can go back across all transactions and calculate the private keys from the signature provided or from the public key and control all the UTXOs from it.

(2) Mining: A classical computer need O(N) operations to go through all the nonces in order to find the solution to the cryptographic puzzle. A Quantum computer would need O(sqrt(N)) to go through the nonces. This would lead to increase in efficiency in the order of magnitude of 10^10 (Tangle whitepaper). If mining is faster with a quantum computer, it could lead to consolidation of mining power if one entity were to acquire a quantum computer while it remains out of reach of others. In that case, the owner of the quantum computer can launch double spend attacks and all other benefits of 51% attack

According to this discussion, signature will need to move to post quantum world much before quantum PoW. This is because, the rough speedup is 2^240 for signatures while it is ~2^40 for proof of work.

  What could be done to prevent attacks on those parameters?

(1) Bitcoin is more resistant to quantum computing than most of the security on which the internet relies. Moreover, if you never reuse addresses, then no one knows your public keys and thus there's nothing for a QC to solve.  For example, when you send some bitcoins to a person, send the remaining change to an account controlled by a different private key. By the time someone gets your public keys/signatures, you've already spent the funds and sent the change to an account created by a different signature. Also the crypto algorithms in Bitcoin can be changed to quantum-resistant ones (see here).

(2) Bitcoin increases difficulty by only by a factor of 4 at a given time. This means we would need a hard fork to change the difficulty to suit that of Quantum computer it the transition does not happen gradually.


How to avoid Bitcoin-QT's transaction fee or change size limit?

You are probably trying to pay with BTC collected from very small payments (known as dust). This dust is commonly collected from advertisement sites. Though they know sending small payments will break your wallet this way, they just don't care as long as you keep clicking ads!

Since transaction size depends greatly on how many payments you're drawing money from, this generates a very large transaction which is very expensive both for miners and other nodes in the network. To reward miners for this cost you have to pay a fee or they will just refuse to mine/broadcast it.

Unless you pay this fee the transaction will be rejected by peers/miners, no matter what you do.

As a workaround you might want to consolidate all the dust sending smaller payments to yourself, but it's a tedious process, still has high fees and might not be possible depending on the concrete amount of payments you've received.


Is it possible to run bitcoind without downloading the blockchain?

It isn't possible with the current version of Bitcoind, Bitcoin-QT is simply a GUI wrapper for Bitcoind so same applies for both.

If you need a wallet that doesn't download the full blockchain go with a thin wallet like Electrum. It does download block heards but that takes seconds. If you want to accomplish your project programmatically, consider the many libraries, such as Bitcoinj, Libbitcoin, and many others.


I don't understand why it seems to be just dividing a single
  transaction without being spent and transferred to someone else

Only Unspent tx i.e UTXO could be spent, and here in your case this  tx is UTXO which after spending to addresses

13MDsVCs3AvSxZxjWUwty2gthPAXkYf6wb - (Unspent) 0.00928291 BTC
1CPp812W35rarR45CS6EYxdC4JazR4H9Wn - (Spent) 0.00231133 BTC

now becomes spent tx

  Why does this transaction results in only 2 unspent output (and no
  spent output)?

This is because lets say this is  your address: 1CPp812W35rarR45CS6EYxdC4JazR4H9Wn where you want 0.00231133 btc, so its one of the output address.
So after sending 0.00231133 to your address leftover balance i.e 0.00928291 need to be stored some where so in that case  13MDsVCs3AvSxZxjWUwty2gthPAXkYf6wb becomes your change address where remaning btc left after spending utxo is sent. Thats why you have 2 unspent op


Can bitcoin transaction be signed offline without access to blockchain

If you know the unspent outputs you have the keys for, yes.

Which in practice means that you need to have seen the transactions that have paid you. Once you know that, the actual transaction to spend it can be created offline.


Hardware Wallet Vulnerability Fix - Verifying Input Value

The way I understand it, the important part is that for BIP-143 each signature is only calculated for the amount that it's own input spends. For the other inputs only their outpoints (txid+txidx) are used for the signature digest.

Let's assume you have two UTXOs, one with 15 BTC at outpoint txid0:txidx0 and another with 20 BTC at outpoint txid1:txidx1.

Then the trick works as follows:

Create a "template" PSBT that contains the correct outpoints in the inputs, so input0: txid0:txidx0 and input1: txid1:txidx1; and an output that sends an amount equal the greatest value of UTXO you have, so e.g. 20 BTC.
Now when you feed this template to your (offline) hardware device, you give the correct UTXO information for e.g. input0 (hence 15BTC+scriptPubkey1), but fake the UTXO amount of input1 so that it adds up to the amount you send + fees (hence 5.000001BTC+scriptPubKey2).
This will leave you with a valid signature for input0, which however is worthless as long as you do not also produce a valid signature for input1 (the one we could have got now for input1 is invalid as the amount was incorrect).
We therefore now repeat the steps, but this time faking the amount of input0 (hence 0.000001BTC+scriptPubKey1), while adding the correct amount for input1 (hence 20BTC+scriptPubKey2). The idea is that it looks similar and the user will simply sign again. This gives you a valid signature for input1.
Lastly, you simply use your "template" PSBT and add for each input the valid signatures you produced. The resulting valid and signed tx then uses inputs of 15 + 20 = 45 BTC, but have as output only 20 BTC, so paying a fee of 15(!) BTC.

// Edit: The fix of adding to each PSBT input the complete transaction containing an outpoint being spend enables the hardware device to check if the amount are correct (otherwise the txid would be wrong).


How to change bitcoind 0.8.1 bind settings?

it seems the following is the answer to both questions:

// bitcoind.conf, v0.8.1
irc=0
listen=0
rpcpassword=<hash>

this results in a 127.0.0.1:8332 and ::1:8332 listen only. i was unsuccessful in locating a command that disables ipv6 listens. the onlynet= command limits peer connection types, not listen types.

listen=0 disables live listens, but does not affect localhost binds.
the bind= command only works if listen=1
note that rpcuser= is set default to root if omitted and only accessible by a user with said credentials. disabling all listens would make the daemon inaccessible by command line. the server= command only works for bitcoin-qt.


Who is responsible for ensuring that the bitcoin protocol is not violated in the network?

There is no single entity responsible for ensuring the rules of the protocol are not violated. Rather, bitcoin is a decentralized network, so all participants must adhere to the protocol’s rules, or else the network will ignore them.

This is accomplished by a network of full nodes, that relay and validate all transactions and blocks against the network’s rules. All of the nodes together form the decentralized network, so to join the network you must adhere to the rules defined by the node’s code.

  The market forces behind the supply and demand of bitcoin

This will determine the price, but the price will not affect the ability of participants to violate the networ’s rules, nor will it ensure that rules are not violated. The rules must be followed whether the price is $1 per bitcoin, or $1 million per bitcoin.

  Miners

Miners work to secure the blockchain record, they will validate transactions in the same way other (non-mining) full nodes do, and they will ensure only valid transactions are added to the blockchain.

  Consensus of the miners

Same as above. Note that even if a group of miners decided to violate the network’s rules, then the network (full nodes) would simply ignore any new (invalid) blocks found by those miners.

  Developers of the bitcoin protocol

The developers collaboratively write and refine the code that runs the network, but this does not give them absolute powers to violate or change the rules. Their code works to ensure that everyone involved in the network is behaving, and that any misbehaving nodes are banned.


NBitcoin: Get address out of raw block stream

my test transaction has a Base160 encoding, so according to my understanding it was sent to an address

I guess you mean ripemd160 or base 16 (hexadecimal) rather than Base160. Ripemd160 is just a hashing algorithm so the output is just bytes, probably encoded in hex (base 16). You can guess it is a ripemd hash based on its length, but not based on its encoding, because the entire transaction is usually displayed in hex.

But to convert from a pubkey hash to an address, you also have to add the checksum onto the end, rather than just the version byte (the 0x00). That is most likely why you are getting a different result, because you have no created a checksum before encoding it with base58.

See the steps outlined here for more info: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address


A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.

If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the x and y coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve secp256k1, but the concept is the same.)


Miniscript or_i, d: - do they always imply a witness input?

Correct. A Miniscript satisfier needs to provide the 0/1 in the witness for these fragments.
To give more than a one-word answer, we assume MINIMALIF in our analysis (for size/fee estimation). Our original design enforced it in script using the opcodes SIZE EQUALVERIFY, but we dropped it because our design assumes standardness everywhere. (If we did not assume standardness we'd have a lot of very expensive checks to add to avoid malleability ... e.g. to check that signatures are either valid or empty is pretty expensive to do in Script).


What do the classes ChainstateManager, CChainState, CChain and BlockManager do in Bitcoin Core?

What do the classes ChainstateManager, CChainState, CChain and BlockManager do?

A graphic from Doxygen showing how the classes interact:

ChainstateManager: Provides an interface for creating and interacting with one or two chainstates
CChainState: Stores and provides an API to update our local knowledge of the current best chain.
CChain: An in-memory indexed chain of blocks. It was introduced in PR 3077.
BlockManager: Maintains a tree of blocks (stored in m_block_index) which is consulted to determine where the most-work tip is.

Why do CChainState and CChain have a leading 'C', but ChainstateManager and BlockManager don't?

C stands for class using Hungarian style naming.
The current style in Bitcoin Core is not to use Hungarian notation. Bitcoin Core uses m_ to represent member variables, g_ to represent globals, and no prefix to represent local variables/parameters. CChainState and CChain were named prior to these style guidelines being implemented in Bitcoin Core.
These were answered by John Newbery and other participants of the May 12th 2021 Bitcoin Core PR review club.


Is it possible to execute a CLTV transaction in bitoin core 0.11 console?

OP_CHECKTIMELOCKVERIFY is implemented as of Bitcoin Core 0.11.2.

This release supports a soft fork to enable CLTV (BIP 65).  CLTV is part of version 4 blocks.  Once 951 blocks are mined with version 4 blocks, then the soft fork is complete on only version 4 blocks are valid from this point on.

You will need to construct the CLTV transaction using other software.  Here is an example that requires bitcore (NodeJS):

https://github.com/mruddy/bip65-demos


1AcJanbHGrBFwS3KJMDW8kEZMtHiJhatzE is a P2PKH (pay to pubkey hash) address. 3BJKWL5ipkVe2bjkRSt6ZNbVWQaRrEFjMs is a P2SH (pay to script hash) address. Their only difference is in the version byte that identifies the type of address.

However, in order to spend a P2PKH output, one needs to reveal the public key with the address's hash160. In order to spend a P2SH output, one needs to reveal the script with the address's hash160.

Given that the P2SH address has spending transactions already, clearly someone knows the script whose hash is 69665e2c4fac771e340f8c6f91c719b0c37a6a8f (namely the script 2 02707f8c41a9ce80bd85c335ce37617388fe8fd5c7b6079f730fc8b7159867cb3e 02f61a255027b492203f04396474e032e759367ad32cdb1b317074e216718f9b53 02ae11e6f80d33717c8dffcbd4e480b95f82f9fe7478cb166beebddd5b062c9f96 3 OP_CHECKMULTISIG, a 2-of-3 multisig script). It is astronomically unlikely that someone also has a public key whose hash is that some value (and much less knows the private key). As a result, it is extremely unlikely that funds sent to the P2PKH address are spendable.


Is it possible to "send" Bitcoin to yourself (new wallet) without announcing it to the network and without paying any fee?

The network comes to consensus on how much Bitcoin is held at individual addresses. If you want the network and the blockchain to recognize a certain amount of Bitcoin is held at a new address rather than an old one you can't avoid broadcasting a transaction and paying a fee. Of course there are offchain methods of transferring value like Lightning and Liquid between addresses but the Bitcoin blockchain does not know of these transfers.


Can addresses used in a single tx be assumed to be from the same wallet?

No, you cannot assume this.

There are a number of ways in which individual inputs may belong to different wallets/owners. For example:

They could come from a hosted wallet or exchange, where inputs may span coins deposited by thousands of individual users, and selected for a transaction with no particular relation to the user making that transaction
Coinjoin techniques allow multiple individual transactions from any number of actors to be combined into a single large transaction, mixing all of the individual inputs and outputs


What is needed to make a bitcoin exchange?

Is there space for me on your team?

I have spent most of this year trying to answer the same question, starting with the recognition that I could solve all the technical aspects (web programming, Bitcoin handling, trading engine, server security, etc.).

Technically, you need a website and a trading engine that matches buyers and sellers. Whilst there are lots of pitfalls---I cannot imagine a better target for cybercriminals than a bitcoin exchange storing lots of online withdraw-able virtual and real currency---all of this has adequate solutions. Not easy ones, as the technical problems occasionally seen at competitors appear to include layer 7 DDOS attacks and some have fallen pray to not storing their clients' bitcoin securely offline (and with adequate internal handling protocols), but this is really not the part I'd consider difficult to do better. To give pointers: Bitfloor is a company that fell victim to this (going out of business over it), whilst MtGox experienced it yet was able to stay in business.

The key problem is the legal aspect of your operation. The bitcoin exchanges you mention work slightly different then, say, an online stock market exchange. The later will basically negotiate contracts, leaving the participating financial institutions to settle these. It all needs lots of regulation to work, and even so the regulators (e.g. the SEC in the U.S.) are needed all the time to settle and fine disputes. Bitcoin exchanges usually require customers to make deposits. This avoids the settlement risk, but, in the eyes of many regulators (not just the SEC, but, so far and in the U.S., FinCEN and state agencies) puts them in a category with money transmitting companies like Western Union, for which there exists alot of costly and time-consuming licensing requirements. The basic idea is to safeguard customers from mishaps at the company, guaranteeing that there is money to pay them from. Today's law enforcement appears to go significantly beyond this rationale behind the law; in the case of MtGox, a US-bank account associated with them was seized for forfeiture to the government for unlicensed operation. You might think this perverts the idea of protecting the customer from a loss of those funds. I've looked into legislation in the U.S., Germany, and the U.K., and it seems that out of these, only with customers from the U.K. at least the national regulator for the money transmitting aspect does not jump to the view that you need a nearly unobtainable license (status as of this spring, with a warning that this view might change if Bitcoin were to grow so much that it would start being used "as money").

Next, you are potentially exposed to alot of fraud. Bitcoin works so well in being final and potentially anonymous that it seems to attract criminals who manage to make banks transfer money but need a way to launder such funds. You can expect that banks will start to notice a statistical association of your business with frequently disputed or outright illicit transactions. Several bitcoin exchanges have lost their bank accounts, presumably over this kind of issue, including MtGox' original EU bank account, Intersango's UK banking, and bitcoin-24's German banking. Fortunately, I think I have read articles claiming that three banks (in Silion Valley, NY, and Munich) have come out as supporting bitcoin exchange businesses if they implement rigorous anti-money laundering rules. I don't have links ready but could probably find them quickly.

Finally, you'll need someone to understand and deal with anti-money-laundering rules and anti-terrorism financing. When I read the laws about these, it sounds to me that you have to do just about everything that you'd think any democratic constitution would prohibit, like spying on your customers, acting on suspicion, keeping parts of the government well-informed and lying to other parts of the government. I'm not joking; see another answer from me. However, these rules obviously have a good reason, and that is not to allow any terrorist, criminal, UN-sanctioned person or entity, etc., to move money or related things of value. I suspect with a bit of guesswork they also explain some of the beef some banks have had with bitcoin exchanges in the past, and their tight-lipped attitude about it.

If it needs spelling out: Following anti-money laundering rules includes identifying your customers (often in the UK way of requiring photo ID and a utility bill), making sure they come from places you are licensed to do business in, checking that they are not on a blacklist, ensuring that data you could be expected to look at do not make them look suspicious. This, and the change of perception of Bitcoin by regulators from something not worth noticing to something to keep an eye on seems to be reason why the existing bitcoin exchanges now all require ID.

I still want to build a bitcoin exchange or a functionally similar alternative. But I need support in dealing with all the legal aspects; getting it right or raising the large sums of money and having the 2 years or so patience for getting licensed in larger US states is beyond what I can do on my own. Again, is there room for one more in your team?


The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction.

To understand this, first understand the concept of a tree. Consider an 8 transaction block. Imagine each of those 8 transactions at the base of a pyramid: these are called leaves. Put four "branches" on the second tier of the pyramid and draw two lines from each of them to the leaves so that each branch has two leaves attached to it. Now join those four branches to two branches on pyramid level 3 and up to one branch (what is called the root of the tree) on the top of the pyramid. (Our tree is growing upside down in this example.)

Now we can start to understand the hashing process. Hash the hashes of the "leaves" and include that as part of the 2nd level branches that those leaves are attached to (these are called child nodes and parent nodes). Now hash the hashes of those hashes and include that as part of the third level branches. And so on. (And if you had more than 8 transactions, all you need are more levels to the pyramid.)

So now you have a root node that effectively has a hash that verifies the integrity of all of the transactions. If one transaction is added/removed or changed it will change the hash of its parent. Which will change the hash of its parent, and so on, resulting in the root node's hash (which is the Merkle root) changing as well.

So how does this help us with potentially not having to have the entire blockchain? Because we could verify the transactions as needed. If we have a transaction that claims to have been from block #234133 we can get the transactions for that block, verify the Merkle tree, and know that the transaction is valid. We can do that without necessarily knowing all of the transactions from #234132 or #234134 because we know that the blocks are tamper proof.

Even better, if we know where it is in the Merkle tree and we know the hashes of the branches we don't even need all of the transactions from #234132. (There were 868 in that block.) We start with just our transaction and its sibling (if it has one) and calculate the hash of those two and verify that it matches the expected value. From that we can ask for the sibling branch of that and calculate the hash of that and verify it. And continue with this process, up the tree. Which only takes ten verifications for 868 transactions. (That's one of the great things about trees, they can hold a lot of values with only a relatively small number of layers.)

How do we know that the source of this data isn't lying to us about the hash values? Because a hash function is one-way, there is no way that a deceptive party could guess a value that would hash with our second-to-last value to create the Merkle root. (Which we know from our verified blockchain.) This reasoning holds further down the tree: there's no way to create a fake value that would hash to our expected value. Another way to think about it, is that even a single alteration of a transaction at the base of the tree, would result in a rippling change to all the hash values of nodes in its branch all the way up to the root's hash value.

In short, the Merkle tree creates a single value that proves the integrity of all of the transactions under it. Satoshi could have just included the hash of a big list of all of the transactions in the Bitcoin header. But if he had done that that would have required you to hash the entire list of transactions in order to verify its integrity. With this way, even if there are an extremely large number of transactions the work you need to do (and the number of hashes you need to request/download) in order to verify the integrity is only log(O).

[As always, feel free to edit this. This is primarily just inference on my part from looking at the spec.]


How are scriptless scripts and taproot different?

One of the most common use of script in Bitcoin is to construct logically atomic operations, such as "Tx2 happens if and only if Tx1 happens".

Scriptless scripts tells us how to use the additive properties of schnorr-signatures to construct atomic transactions without using script. Doing so this way will make them more efficient and private.

Taproot is an idea which uses the additive property of ECC public keys to allow users to commit to a script which is only revealed if needed. If it isn't needed, it is never even revealed that a script existed at all.

This is useful because almost all sensible contract terms (both smart and otherwise) can be rewritten as a top level OR between "Everyone agrees" and the actual contract, and because (with schnorr) you can make a single signature work for the everyone agrees case.

Taproot itself doesn't depend on the specific properties of schnorr and could be implemented e.g. for ECDSA. Technically taproot works outside of the EC signature itself to allow you to spend either via a single plain signature OR some other conditions, with the existence of other conditions hidden if you spend via the signature. But with ECDSA it isn't easy to use a single public key to represent the "everyone agrees" case, so taproot would be much less useful.

So, for example, if you had an output that could be spent either by Alice or by Bob but only after a time limit then pattern would be more efficient with ECDSA taproot than without taproot: Alice's key would be used to generate the root, and bob's key and timeout would be in the hidden script.


What's the worst-case delay for BTC->USD?

When the BTC funds are on your MtGox account, a market sell order is nearly instantaneous and so done in a few seconds, dependent on the amount you buy.

Depositing Bitcoins to MtGox requires 6 confirmations before they show up in your account. 6 confirmations means 6 blocks to be mined since your transaction, this will averagely take 1 hour to complete.

The time for withdrawing your US dollars will strongly depend on the withdrawal method you want to use.

Note that there are many other exchanges and so this answer only holds for MtGox. It's likely that other exchanges require less confirmations and/or have faster withdrawal methods.


Not that I know of. Opencoin is still playing around with the protocol, so there probably won't be a white paper until they open source it.


Just in case someone is wondering the same, mining from a small 10W USB ASIC miner is not really a fire hazard if you take proper precautions:

let air flow around the device
don't place it near easily flammable material

But as I have experienced, I was on average 5 MH/s which is not going to get me very far.


Old Wallet, Private key and known public address

Your wallet will contain a collection of private keys, and it should show you the balance of the addresses associated with those keys.

For the public address you mentioned, if you have the private key associated with it, you'll be able to spend the coins. If not, there is no way to recover a private key from a public key. The private key is either known by the wallet file, or not. There is no way to 'resend' a payment, etc, to recover a private key that is otherwise not known.


These are called Namecoin blocks and you can see your reward for all those blocks by checking out your reward section. You'll see a toggle above the rewards table on the right to switch between Bitcoin and Namecoin blocks. These blocks have a much lower value than normal Bitcoin blocks and so your reward is very small. The number of confirmations needed for these blocks is also very small compared to normal blocks. They are a by-product of Bitcoin mining and the pool uses a service to automatically exchange them for Bitcoins.


If I send a BTC to an offline cold storage, does the transaction in the blockchain appear when i send it or when i receive it or not at all?

It seems that you have a misunderstanding of how Bitcoin transactions work.

Transactions are not things that are sent directly to the receiver. The recipient does not need to be online to receive Bitcoin as they do not have to do anything to acknowledge a transaction. Instead, when you someone Bitcoin, the transaction you create is broadcast to the entire Bitcoin network. Whether the recipient receives the transaction is irrelevant.

Once the transaction is broadcast to the Bitcoin network, a miner should include it in a block and thus it becomes part of the blockchain. Being included in a block means that the transaction has "confirmed". While it is not in a block, it is "unconfirmed".

If the recipient is offline when you broadcast the transaction, and the transaction confirms (i.e. is included in a block) while they are offline, they will see the transaction in the blockchain as they sync the blockchain.

So in your example, the transaction will be broadcast to the network, and a miner will include your transaction in a block. It does not appear in the blockchain when you send it, but it will appear in it shortly after. Whether your cold storage wallet is offline or online does not matter as there is nothing that needs to be done by the recipient in order to receive Bitcoin.

Block explorers generally listen to the Bitcoin network for unconfirmed transactions, so as soon as they receive your unconfirmed transaction, they will make it searchable. If they don't see it, once it is in a block and they receive the block containing it, they will display it as well.


If you're talking about the bulletproofs research or the bulletproofs topic, use "is".

If you're talking about the individual proofs, use "are".

Bulletproofs is shaping the future.
Bulletproofs is an important protocol.
Bulletproofs are short and don't require trusted setup.
Bulletproofs are going to replace the usual signatures.
Bulletproofs is going to replace the current signature protocol.


Where does one obtain the most widely accepted Bitcoin/Euro exchange rate?

Bitstamp is reputable and generally accepted in the context you've mentioned.


Using paper based public/private keys in bitcoin-qt

I  haven't tested this myself yet but I understand that you can use the info from a paper wallet and generate a transaction using http://brainwallet.org, that said brainwallet.org make some rather nice paper wallets much more info included the the blockchain.info paper wallet.  Let me know if you send a Transaction using this would be interested to know if it works and how simple it was....


Is the output script generated by my program?

Yes.

  scriptPubKey refers to Public Key of?

Whoever you're sending the bitcoins to.

  So, now, once the output script is formed, is it broadcast over the Bitcoin Network?

After it's signed, yes.

  Where does the Input Script come from?

It is composed of two pieces - your public key, and a valid signature corresponding to that public key. So, you make it.

  the scriptSig in Input Script refers to the Public Key and Signature of whom?

You.

  When I am sending Bitcoins to a Bitcoin Address, the input Script is automatically generated by what?

Your client, after looking at your wallet.

  Even though the wiki gives details about Input Script and output Script, I was unable to correlate it to a real time scenario where one person sends BTC to another.

There are two parts to a bitcoin transaction - the part where you prove that you own some bitcoins, and the part where you designate someone else to be able to prove they own some bitcoins.

  So, the Public Key in scriptPubKey differs from the Public Key in scriptSig?

scriptPubKey is very poorly named, because when you're sending bitcoins to an address, you only know the 160-bit hash of the public key. A scriptPubKey looks like this:

OP_DUP OP_HASH160 06f1b670791f9256bffc898f474271c22f4bb949 OP_EQUALVERIFY OP_CHECKSIG

The 06f1b6... is how your client specifies who it's sending to. The parts around it are scripts that tell the bitcoin client how to validate the transaction.

  Also, we only have the Bitcoin Address of the person we intend to send the Bitcoins to. How do we get the Public Key of the recipient?

We don't need to. We can tell the network the 160 bit hash, and the person you're sending to can show the public key to the network when they want to spend their bitcoins.


Spending bitcoins - what happens to the change left in your address?

I assume you're using Bitcoin-Qt, i.e. the reference implementation.

Bitcoin-Qt works with accounts, not addresses. The balance of your wallet is the sum of each account balance. The purpose of accounts is to compartmentalize payments in labels such as "Savings", "Salary", "Friends", etc. for your own convenience.

Each account has many Bitcoin addresses associated with it, though you'll only see one at a time (the last one). As soon as you get a payment in the displayed address, its address will change. You can still receive payments at that address, though that is considered bad practice due to anonimity issues.

Now to answer your question: "I read that when I buy something [...] I must then spend the rest to another unused address [...] as the first address becomes unsafe or the change is lost in mining fees or something."

Bitcoin works a bit different than money. A payment is:

References to earlier payments you received (i.e. the sources of money)
A list of pairs of (address + amount) (i.e. destinations)

When you reference an earlier payment you must spend it as a whole. You can't split it, like you wouldn't be able to split a 10€ bill in two 5€ bills.

For example: let's say you receive 10BTC payment. If you want to spend 1BTC you can't split it in 1BTC (paid) + 9BTC (left in address). You have to spend it all!

On the other hand, that's pretty much like paying 1BTC to someone else and sending 9BTC back to yourself. You could pay yourself to your original address, but Bitcoin-QT is smart enough to create a new (invisible to you) address which receives this change. The advantage of this "change address" is that I can no longer link your payment back to yourself:

Did you spend 1BTC and sent 9BTC as change, or perhaps spent 9BTC and sent 1BTC back as change? If you reused the same address, the change is obviously the one with the same address. If you let Bitcoin-Qt take care of it both will be new addresses and the money can't be traced back to you. This is what you meant with "the address becomes unsafe".

The key is: don't worry about this! Bitcoin-Qt will take care of all this for you! As long as you understand your accounts, addresses are disposable.

Now... what happens if Bitcoin-Qt somehow didn't send the change back to you? Imagine you just said "I want to send 1BTC out of this 10BTC" but Bitcoin-Qt forgets to send the change (this WON'T happen using Bitcoin-Qt, it's just a thought experiment).

Transaction fees are the difference between input and output, i.e. input - output. If somehow you only send 1BTC but forget to send back 9BTC of change to yourself, whoever mines this block will get the leftovers!


Is Ripple an anti central exchange that makes Bitpay and Mt.gox almost obsolete?

Ripple supports a distributed currency exchange; anyone can offer to exchange from one currency to another. These offers are taken when a counter offer the same or better is made.

Like any exchange between two parties, the price would be based on supply and demand, world events, what the market will bear, etc.

The advantage is there’s no single point of failure that would cripple the market. We’ve seen what happens to bitcoin when Mt. Gox goes down or is under a denial of service attack. That’s obviously not a problem with decentralized exchanges.

And with the new Bitcoin Bridge feature of Ripple, you can pay anyone in Bitcoin from a Ripple wallet. The currency exchange is done by an organization (a.k.a a gateway I believe) running the freely available Bitcoin Bridge protocol, like Bitstamp. You can see as of this moment, the Bitstamp rate is $98 per Bitcoin. You can see the exchange rates of the exchanges at Bitcoin Average.


Checking the Merkle Root for Block #100000

You have to byte-swap the transaction ID's before hashing them, hash each child node, and byte-swap the final hashed hex value.

Transaction 1 (Coibase Transaction)
8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87

To Byteswap it you can use:

a = "8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87"
"".join(reversed([a[i:i+2] for i in range(0, len(a), 2)])) @Greg Hewgill

Byteswapped = 876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148c

Transaction 2
fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4
Byteswapped = c40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff

You want to concatenate the byte-swapped transaction values of 1 and 2. Transaction 1 goes first.

876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148cc40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff

To hash this hex string you can use the following code running Python in your command terminal:

      import hashlib

      transaction12_hex = "876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148cc40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff"

      transaction12_bin = transaction12_hex.decode('hex')

      hash = hashlib.sha256(hashlib.sha256(transaction12_bin).digest()).digest()

      hash.encode('hex_codec')

      15b88c5107195bf09eb9da89b83d95b3d070079a3c5c5d3d17d0dcd873fbdacc

Transaction 3
6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4
Byteswapped = c46e239ab7d28e2c019b6d66ad8fae98a56ef1f21aeecb94d1b1718186f05963

Transaction 4
e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d
Byteswapped = 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9

If you do the same thing for transaction 3 and 4 the final hash is: 49aef42d78e3e9999c9e6ec9e1dddd6cb880bf3b076a03be1318ca789089308e

Our last step is to combine the final hashed value of 1 & 2 and 3 & 4 and double hash it and byte-swap it.

Our answer is f3e94742aca4b5ef85488dc37c06c3282295ffec960994b2c0d5ac2a25a95766 the Merkle Root.


Is mining a fair mechanism in blockchain network?

Considering that a block is mined on average every 10 minutes and that the average time to propagate to all nodes is 12.6 seconds, I think it is pretty fair.

We could also guess that the big miner have incentives to get the newly mined hash very fast so it must be lower than 12.6 for them.


sendfrom has these parameters:

sendfrom "fromaccount" "toaddress" amount , minconf, "comment" "comment_to"

As you can see there is no subtractfeefromamount boolean parameter.So you can't deduct fee from the amount itself.

You can use sendmany option with single destination address. sendmany has these parameter:

sendmany "fromaccount" {"address":amount,...} ,minconf, "comment", subtractfeefrom

Here subtractfeefrom in above parameter accept array of address from which fee will be deducted.

example:

bitcoin-cli sendmany "1521" "{\"n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1\":0.01}" 1 "" "[\"n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1\"]"

n3jYBjCzgGNydQwf83Hz6GBzGBhMkKfgL1 will get 0.0098(approx) and not 0.01


Can I find a list of possible error codes and their meanings for bitcoin-cli?

Here is the list inside the Bitcoin Core v0.15.0.1 source code:

https://github.com/bitcoin/bitcoin/blob/v0.15.0.1/src/rpc/protocol.h#L32L87


Actually, nobody else can create a valid signature for your transaction inputs, as they do not possess the private keys to do so.

When a transaction is malleated by a third party, it is not re-signed, merely it's signature is changed. ECDSA signatures are malleable, in that taking the negative of number S (modulo the curve order) does not invalidate them. As the TXID is created by hashing the complete transaction data, this will result in a new valid transaction with identical payload except for a new TXID.


Is Proof-Of-Work simply a decentralized clock?

Yes, PoW is a decentralized clock not just for tying information to a specific time (a timestamp can do this perfectly fine) but to prevent spam attacks on the blockchain itself.

The question comes up, how can you add data to everyone's ledger all at once continuously and efficiently? If there is a single tx at a time queue system then things will be unbearably slow.

If the ledger is open for everyone to add verified transactions then what's to stop someone from just adding transactions on transactions and filling up everyone's node?

PoW exists to solve this problem by creating something like a flood gate that allows only a set amount of transactions per time. The difficulty aspect of PoW exists to adapt to the changing nature of computing power against the network.

  The clock has an interesting property - you can tie data to its ticks, simply by making the data the input to the SHA. A solved block is nothing more than simply an event that happened exactly at the tick of this clock.

This is so an attacker can't just use the same verified data to add blocks and blocks of transactions. Think of a block mined by the miner as a one time use token that let's the block be added.

  An analogy might be looking for the largest known prime. You don't need to tell anyone you decided to find one, you only announce when and if you actually find one. Your participation makes finding a solution a possibility, whereas if no one ever looks for the largest prime, it will never be found.

This portion isn't entirely correct. For you to test if a block you've mined is correct (because mining is entirely a guessing game) you need to ask the network if the block is valid. More than likely the node you just asked will say no and you begin the search again.

Although I should note that the amount of failed attempts is not factored by the difficulty algorithm


You can find how to read the blockchain leveldb (format and meaning of the keys) here: What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?

no idea (yet) for the UTXO :-)


How much data traffic does participating in P2Pool mining cause?

According to Greg Maxwell:

4.14kB/sec in, 10.7kb/s out; averaged over the last 30 days. 38GB in transfer total.
Significantly less than the full node that goes with it... p2pool used to be fairly large relative to the node; but greater amounts of load on the Bitcoin network have shifted the balance.


I have never heard of CoinPot However, if you're referring to the cryptocurrency exchange Coinbase, as of November 2018 it is only possible to store the following coins:

Bitcoin
Bitcoin Cash
Ethereum
Ethereum Classic
Litecoin
USDC
Basic Attention Token
0x

This may be different depending on your location (country), use the chart provided to confirm.

Coinbase makes it fairly easy to receive coins, simply press "Receive" under the preferred coin and submit that address in CoinPot's withdraw implementation (You may need to obtain documentation or contact them for instructions on how to do this).


How can a Bitcoin consumer and a Bitcoin seller mediate disputes?

I'm a mediator and this is an interesting subject. In the conventional world it's seller beware, as the customer can either not pay at all, or charge back a credit card. In the case of Bitcoin, the situation is reversed, and payment once made is gone. I don't think that the issue is with the bias of the mediator, most are neutral, but I do think that a mediator can help to assess the intentions of the parties and a clear path to resolution. It all depends on the intentions of the parties and their willingness to correct whatever is not right about the transaction.  A good mediator can point the way forward in that discussion.


RPC getBalance only works with addresses valid in the local wallet. Once txindex is enabled, RPC getrawtransaction will return transaction data for any address on the blockchain.

Calculating the balance for an arbitrary address is possible because almost every blockchain explorer does it. However, calculating a balance for an address using RPC getrawtransaction is not possible.


Last time to send Bitcoin to Trezor before fork

Bitcoin Gold will fork at block 491407, which means that the first Bitcoin Gold block will be at height 491407. So as long as your transaction confirms before block 491407, your transaction will exist on both blockchains.


Is a Trezor hardware wallet dependent on wallet.trezor.io?

No, a Trezor is not dependent on trezor.io or SatoshiLabs still existing. You can use a Trezor with any wallet software that has implemented support for Trezors. One such wallet is Electrum.


A "bad attempt" (i.e. a block whose hash is above the target) isn't "crossed out".  It is entirely possible that you will later find a different block whose hash has that same value.  Nothing prevents it.  Every hash behaves like an independent trial.

It's easier to understand with smaller numbers.  Say you have a 6-sided die and you want to roll it until you get a 6.  If you roll a 3 on the first roll, that doesn't "cross out" the number 3; it is entirely possible that you will roll 3 again on future rolls.  The die has no "memory".  For that reason, there is no guarantee that you will get a 6 within 6 rolls; there's a chance it could be 7 rolls, or 12, or 100 rolls, before you get a 6.

Even if this were true, it wouldn't really make much difference: the number of hashes that you, or all the world combined, have ever computed, is a negligibly small fraction of the total number possible.  2^256 is an extremely large number.

http://bitcoin.sipa.be/ estimates that a total of 10^26 hashes have been performed on the Bitcoin network to date.  That's  100000000000000000000000000.  The total number of possible hashes is 115792089237316195423570985008687907853269984665640564039457584007913129639936.  So about 0.0000000000000000000000000000000000000000000000001% of them have been seen so far.  Even if they had been somehow "crossed out" it would not appreciably change the number that remained.

As to number 2, you are correct: since the goal is to find a hash that is less than the target, a smaller target means it is harder to find a successful hash.  The number usually called "difficulty" is computed as the maximum possible target (which is 2^224) divided by the current target, so a smaller current target means a larger difficulty number.


Why is the output address a list in RPC/console?

This is due to historical confusion between addresses and keys.

The original goal of this field was reporting the public keys involved in raw multisig outputs. However, those public keys were referred to by the P2PKH address corresponding to them.

This is confusing because obviously every output only corresponds to a single address. The feature is also useless now due to the introduction of P2SH, where instead of putting all public keys in the output, just a hash of script involving all those keys is stored.


then you have 25 letters in base58, and that's like 17 bytes.

20, actually.

  So, you have to pay like 0.0001 BTC for the transaction fee, and after that you can add data to that transaction at a price of 17bytes per 1 satoshi, by sending satoshis to many addresses that contains the whole data. Imagine if we could store data there forever,.. and communicate with the future...

You're going to run into two problems with this: transaction fees and dust rules. Transaction fees mean that each transaction will cost you a couple of cents. Dust rules mean that transactions with outputs below a certain size will simply be dropped. The rationale behind this is that you're sending a transaction so small that the fee required to redeem it will be more than the money that you're sending.

In the longer term, the data you're sending is going to look identical to all of the other data that's in the blockchain. That means that you need to identify your transaction somehow. That's usually done by providing the txid, which is 32 bytes.

  Is this technique a good practice?

It depends on what you're trying to accomplish. For example, are you trying to communicate anonymously? You should use BitMessage via Tor instead. Do you want to embed transactional data, like Counterparty does? Embedding the data in Bitcoin is probably the best solution for that.

  ... and communicate with the future...

Well, the Internet Archive crawls all webpages (including this one!) so you're already uploading the things you've typed into a distributed, long-lasting datastore.


The Finney attack is named after Hal Finney, who suggested it in this comment. (Hal happens to be the first recipient of a Bitcoin transaction, and the first person to comment on the release of the Bitcoin source code.)

It is a double spending attack with the following features:

It only works if the merchant accepts unconfirmed transactions.
It still works, however, if the merchant waits a few seconds to
verify that everyone in the network agrees he was paid.
It requires the attacker to be mining and controlling the content of
his blocks; however, he can in theory do this with any hashrate, in particular significantly less than 50% of the network hashrate.

It proceeds as follows:

The attacker mines blocks normally; in the block he is trying to find, he includes a transaction which sends some of his coins back to himself, without broadcasting this transaction.
When he finds a block, he does not broadcast it; instead, he sends the same coins to a merchant for some goods or service.
After the merchants accepts the payment and irreversibly provides the service, the attacker broadcasts his block; the transaction that sends the coins to himself, included in this block, will override the unconfirmed payment to the merchant.

If the time from finding the block until the attacker sends payment and the merchant accepts it is t, and the average time to find a block is T, there is a probability of t/T that another block will be found on the network in this time; in this case the attack will fail, and the attacker will lose the block reward of B.

This means that the average cost of attempting the attack is about (t/T) * B; as a rule of thumb the merchant should wait at least t=V*T/B (V is the value of the transaction), to make sure that trying to carry out this attack against him isn't profitable; this may not be sufficient though, as a nimble attacker can use the same block for multiple attacks, potentially gaining the total of their value.

Clearly, the lower the attacker's hashrate, the less opportunities he has to carry out the attack. If the attack is for obtaining some illiquid good, it is difficult to make the need for this good coincide with finding a block. If the attack is for obtaining something liquid (e.g. exchanging bitcoins for other money), an opportunity is ever-present but the merchant is likely to require a few confirmations. This makes the attack difficult to use in practice.


Here is how to install and Launch LiteCoin Core daemon on your machine :-)

A Litecoin full node for building applications and services with Node.js

1. Download Litecoin core from official website https://litecoin.org/
 =>extract that file
2. tar -zxvf litecoin-0.16.0-x86_64-linux-gnu.tar.gz

=>install it
3. sudo install -m 0755 -o root -g root -t /usr/local/bin ~/litecoin-0.16.0/bin/*

=> Create configuration file
4. now create configuration file(~./litecoin/litecoin.conf)

=>now start litecoin node with daemon
5. litecoind


Bitcoin-qt transaction not initiated by the wallet owner

Your hypothesis of a Trojan seems likely, unfortunately. Just be glad you didn't have more coins in that wallet.

You'll probably want to wipe and reinstall the computer in question.


How does Bitcoin protect against doublespends?

No one on the network has a 'balance', they just have the keys to the outputs of previous transactions which they haven't spent yet. At the start, Alice holds the keys to some Unspent Transaction Outputs (UTXOs), totalling a value of $10 bitcoin. That's what you mean when you say she has $10.

When she makes a transaction to Bob or Joe, she uses those UTXOs as input for the new transaction. But because she only has $10 worth of UTXOs, if she uses the same UTXOs in both transactions, only one of them can be valid because you can't use the same UTXOs twice. So only one of the two transactions can be added to the chain, correct. The one which is added will just be the one which the miner of the block saw first usually. Some miners might see the transaction to Joe first, and try to mine that into a block, while others may see the one to Bob and try to mine that into a block.

The consensus is just whichever miner finds a valid block first, then the transaction that miner included (let's say Bob's) will be part of the longest valid blockchain and all the other nodes will accept it. Nodes trust the longest of the valid blockchains (note that it has to be valid, no honest node will accept invalid blocks or mine on top of an invalid chain to extend it), so if that longest chain contains the transaction to Bob, Alice's previously unspent outputs will now be deemed spent, and instead Bob will have the keys to the new outputs of the transaction (because Alice used his public key/bitcoin address). The nodes will then drop the transaction to Joe because it is now invalid, and Bob has his $10.

For an attacker to change which transaction was accepted after it has been mined into the block chain, he would have to mine an alternative chain containing the other transaction, and race against the rest of the network to make his chain the longest. He will be the only miner to extend the chain if it is shorter, other miners will focus on the longest chain, so he would have to have at least 51% of the mining power of the network to extend his chain faster than the honest miners extend the accepted chain.

It's the same behaviour as if only one unique transaction was sent to the network, in that case all the miners will be trying to include that one instead of some trying to include the different one, so there won't be any outcome uncertainty.


How to get instant notification of any Bitcoin transaction involving a specific public address as recipient without knowing the wallet or private key

If you want to do it via bitcoind, since the transaction in question isn't an in-wallet transaction, this is as close as you can get with bitcoind: GetPublicTransaction()

If your daemon has its transactions indexed (is -txindex enabled), you can iterate through all blocks using getblockash and getblock, then iterate through all the transactions for each block using getrawtransaction and look for outputs and inputs referring the address(es) you want, when it's an input reference then balance decreases, when it's an output reference the addresses balance goes up.

Obviously this approach will take ages in you need to scan the whole blockchain that is getting bigger every day so you need to limit your iterations to the new blocks only, and for newly added addresses to watch you should allow a few minutes for the blockchain to be rescanned if you wish to provide historical data for them.

Apart from that, there is some talk going on about adding support for watch-only wallets (which is what you're actually asking here) in the core client itself, however this enhancement is not yet available today.

You can also sign-up for http://www.blocknotify.com/ and get a notification every time something changes in that address.

Finally, you can parse the local blockchain files manually but that's a little bit more hard-core, this is a nice post giving some guidance on that: http://codesuppository.blogspot.gr/2014/01/how-to-parse-bitcoin-blockchain.html and an open source project that could also help: https://github.com/jeffchan/blockchain-parser


How do exchanges store and transfer bitcoin?

It is important to keep in mind that addresses are not the same as wallets. A wallet contains multiple addresses, not each address is a wallet.

Exchanges maintain their own wallet with thousands of addresses and thousands of coins. When you deposit Bitcoin at an exchange, they will give you an address from their wallet, and you are sending to their wallet. The Bitcoin is now theirs. When you withdraw from the exchange, they send Bitcoin from their wallet to the address that you provide. When they send, their wallet uses some coin selection algorithm to select which coins it will spend to send to you. Since an exchange processes thousands of deposits and withdrawals per day and since the coin selection algorithm may include some randomness, the addresses associated with the coins being spent for each withdraw that you make will likely be different.