In order to correctly show balance and be able to create new transactions, a thin client needs the following information:

Current block number
OutPoint information - hash of the incoming transaction and position of the output relevant to the client.
Signature script, as it needs to be included in a Tx
Amount of Bitcoins send/received in the given transaction
Block number in which the transaction was included (for knowing the amount of confirmations)

(Does anyone have an idea what else could be useful or needed?)


Where does the Bitcoin Core code serialize the number of transactions?

The transactions are passed in as a vector. Bitcoin Core's serialization framework understands that all vectors should be serialized with a compact sized unsigned integer preceding the serialization of the data within the vector itself.


HASH160 to address - What am I doing wrong?

You don't hash the OP_HASH160 {scriptHash} OP_EQUAL, that's just a template associated with P2SH addresses. You need to hash the redeem script, add version byte and checksum and then encode into base58.

Sample Python code:

def p2sh(script):
    scripthash = hash160(script)
    data = b'\x05' + scripthash
    checksum = sha256(sha256(data))[:4]
    address = data + checksum
    return base58.encode(address)


Finally I found the answer: the path is m/44'/156'/0'/0/0, it gave me expected GX1FXv2PrRSARyctabywsi5X58teAjYFU4 address.

Address header should be 38, dumpedPrivateKeyHeader same as in BTC (=128).

For those, who is seeking parameters for different bitcoin-like altcoins: I found many of them in the Coinomi repository.

UPDATE1: As it was mentioned by @john-doe, if you want to reproduce the address this way, you should switch to BIP32 tab and enter the path without the last segment (it would be added automatically for generated addresses).


Hardware wallet teardowns and side channel attacks

The researcher Jochen Hoenicke has done some work on the Trezor. He was able to extract the private key by monitoring the power cable with an oscilloscope.

Trezor has since updated the firmware to defeat the described attack.


How do I recover an encrypted bitcoin wallet to which I don't know the password?

Sorry for your loss.

If he used early versions of Bitcoin, he may have made an unencrypted backup of his wallet.dat file somewhere. Cracking a password may be impossible, so this might be your next best option.

Wallet encryption is a feature that was implemented in version 0.4.0 on 23rd Sep 2011, so if you do find a wallet.dat file older than that it's probably not encrypted.

Bitcoin users that are aware they are holding a substantial amount of bitcoins also are probably aware that they need to back their wallet.dat file up to a location different to their PC's hard disk in case of failure. You might find it on a DVD, thumb drive, or maybe somewhere like Google Drive.


ELI5: How do I import keys from blockchain.info backup into MultiBit 0.5.18

Support for importing blockchain.info wallets was removed in MultiBit 0.5.18. MultiBit still hosts their old releases, however, so you could simply download 0.5.17, import the blockchain.info wallet, and then upgrade to 0.5.18.

You could also import the backup into a new blockchain.info account. Once it's there, you could send it to a MultiBit address or make another backup in an easier-to-read format (e.g. unencrypted export). You could then follow the instructions here to import those private keys into MultiBit 0.5.18.


You can use pywallet to import the wallet.dat and export the private keys.
Then you can just sweep them into electrum or any other wallet supporting WIF.
Pywallet can be downloaded here: https://github.com/jackjack-jj/pywallet


Why is Bitcoin's unconfirmed transaction count rising and what effect does it have on the network?

Yes, you are correct.
In mempool = Unconfirmed.
Blockchain = Confirmed.

A transaction with 1 input and 1 output is approximately 192 Bytes.
Using 20 Sat/Byte will result in 0.0000384 BTC in transaction fees. However in real-life, most transactions have more than 1 input and 1 output. So on average the fees are much higher.

If you take a look at Johoe's Mempool Statistics, you can tell that about 1/4 of the transactions in the mempool are sent with 50Sat/Byte or lower. These transactions will probably be stucked for a long time, or dropped gradually when they reach their mempool expiry time(default 2 weeks for Bitcoin Core v0.14.0 and later).

  Will this ever out-scale the number of miners on the network?

Not in the sense that the network will go down, the target solve-time of a block is 10 minutes. It doesn't matter if there are 10k miners or 10 million miners, the mining difficulty will over-time be adjusted so that the average block time approximate to 10 minutes given the total hash rate of the network.

At this rate, where there are more incoming transactions than what the network can process. The network will be more and more congested and eventually a lot of nodes mempool's will be saturated(if they have set a max cap), and new transactions will be rejected.


Is selfish mining still an option with compact blocks and FIBRE?

While FIBRE has done an incredible job in reducing relay times for blocks which are new, many miners additionally have systems by which they relay their own blocks in a single packet and have them queued up to relay on when they start mining the template, not when they find the block. Ultimately, FIBRE's few milliseconds of delay will lose to a single UDP packet that just relays the winning nonce around. Further, selfish mining attacks are very non-linear in the advantage you gain from a relay advantage - if you're 1ms faster to most hashpower, you have an advantage to that hashpower, period.


Why do altcoins vary so along with bitcoins?

The answer is that many altcoins are traded in BTC/ALTcoin pairs, not $$/ALT pairs.

So if an altcoin is trading 0.1 BTC/ALT, and the dollar price of bitcoin falls, then the $ price of the ALT will fall an equal amount.

Some altcoins trade against dollars as well, so their dollar price may be less coupled to the BTC dollar price. But for many of those alts, a large amount of the trading volume will still be from the BTC/ALT pair, and so the influence is still there.


You may miss rpcport number in configuration file.

Run nano ~/.bitcoinatom/atom.conf

Add new line rpcport=7332 for mainet or rpcport=17332 for testnet

Kill the process and restart server

Ref: https://github.com/bitcoin-atom/bitcoin-atom/wiki/Mining-Instructions


Why can't the genesis block be found I create an altcoin?

Thant is correct. You have to mine the genesis block first separately if you are compiling the most recent bitcoin codebase.

Checkout : https://github.com/vlamer/genesis-block-generator


What is "segregated witness" and how can it improve network scalability?

It's not a silver bullet solution, but it's a really good start.

As Gavin Andresen has said, Segregated Witness is a poor name. The 'segregated' part of the name is there to denote that there is separation being done. The 'witness' portion of the name comes from the fact that digital signatures are often time called witnesses.

Segregated witness splits up transactions into different parts that can be handled separately instead of the single chunk of data as they are now. Specifically, it takes the digital signatures out of transactions and puts them in a separate merkle tree that has the same structure as the transaction merkle tree. So, if fully implemented, to check that an input legally spends its previous output, you would get the signature from the signature tree, instead of the standard scriptSig field.

These are a few of the benefits of this idea:

Since signature data (witness data) is stored outside the transaction (and outside the standard block), it means that that data doesn't have to be counted towards the block size. Pieter Wuille is proposing a 75% discount on space taken up by signature data, meaning that you can fit 4x as much signature data into blocks. This effectively results in a soft fork increase to the block size.
Completely solves malleability issues. Using transactions with the signature data outside the transaction means that TXIDs don't hash the signature data, which means that they're not malleable (assuming you're using the standard SIGHASH flag). Technically, the signatures are still malleable, it's just that modifying them doesn't invalidate chains of transactions because the signatures don't sign the modifiable parts.
Allows for a slow upgrade. Software has to opt in to using Segregated Witness after it has been fully deployed to the network, but in the meantime (and afterward) transactions can still be made as usual without segregated witness.
All future Script updates become soft forks. When segregated witness gets fully implemented, it will have a version byte in outputs for what version of Script it is using. And the behaviour for clients that see a script with a non recognized version number is that they treat it as an 'anyone can spend' output.
Signatures only prove that a transaction is authorized, it doesn't describe where funds are going or where they came from. So, after they're checked they can be discarded. Putting the signatures in a separate data structure makes it much easier to prune that data, which results in much less blockchain data needing to be stored on your hard drive.

However, this doesn't completely increase the block size, it just increases the amount of signature data that a block can store. Since transactions are roughly 60% made up of signature data, this is still a pretty big gain.

The downside is that it's a non-trivial upgrade for the network to start using segregated witness. The transaction serialization format is different, and code everywhere that makes bitcoin transactions needs to be updated. Since it's an opt-in process, though, upgrading can be done slowly over time.

You can watch Pieter Wuille's great talk on Segregated Witness at:

https://www.youtube.com/watch?v=fst1IK_mrng&feature=youtu.be&t=37m12s.


These testnet outputs are not making sense to me


How to properly terminate a bitcoin-qt process?


address in listaddressgroupings and getnewaddress

I don't understand the difference between listaddressgroupings and getnewaddress

listaddressgroupings is very different from getnewaddress. listaddressgroupings just shows you addresses from your wallet that have been used. getnewaddress gives you a new address for you to receive Bitcoin at.

  What address is it?

That address is an address in your wallet. The reason you see it listed in listaddressgroupings is because you used generate. generate mines blocks and sends the block reward to a newly generated address. So after using generate, you will see a new address in your wallet which has the Bitcoin received from the block that was just mined.

listaddressgroupings is not giving you a new address every time you call it. If you just call it without mining any blocks and without using getnewaddress, then you will see the same addresses there. No new addresses will be created.

  Why this address begin with 2 and not with m or n ?

The address that generate uses is a P2PKH address which begins with m or n. However the wallet will give you, by default, addresses that are P2SH segwit addresses which will begin with 2. This can be changed by setting the -addresstype option to change the address type that getnewaddress will give you. This discrepancy is largely due to legacy reasons; there's no reason that generate couldn't use P2SH segwit addresses (or whatever you have set addresstype to) but no one bothered to change it.

(Note that generate doesn't actually use P2PKH outputs. Rather it uses a P2PK output which does not have an address type. For convenience, this is displayed as a P2PKH address)


How does Stellar multi-signing happen practically?

The coordination of the tx envelope before it has the right number of signers happens by some other channel. If you and your friend both need to sign for any tx from an account, you would sign it and then email or IM the tx_blob to your friend. Your friend would then add their signature to the tx_blob and submit.

If your enemy signs a tx you can simply remove your enemy's signature before submitting it to the network.

If someone doesn't sign then the server you submit the tx to will reject it immediately.

Source: Multisig and Simple Contracts


It is possible to build a P2P system to trade Bitcoins?

I think the answer to this question is currently unknown.  There's currently an ongoing discussion about it on the bitcointalk forums.

I'll update this answer if anything comes of it.


If mining isn't profitable, fewer people will mine. That means the difficulty will drop, increasing the profitability of mining. That means more people will mine. The system is, by design, self-regulating.


How do mining pools protect their wallets?

If a pool makes a payout, the mechanism that performs the payout must have use of a private key. Therefore I don't believe there can be any secret to securing this private key beyond good operational security best practises. This would include operating with a minimum of "cash-on-premises", so the wallet used by the payout mechanism would only have enough BTC to cover payouts for the next few days, relying on refills performed by an entirely separate, manual process.


Those are Pay to Pubkey scriptPubKeys. P2PK is in the format <pubkey len> <pubkey> OP_CHECKSIG. The 21 is the pubkey length and the 03 is the first byte of the pubkey. The ac is OP_CHECKSIG.


Determining if input is a block ID, transaction ID, or address

As outlined in the pseudocode in amaclin's answer, a block explorer website would simply check to see if they can find the hash/txid/address in their database, then they will know what type of input it is.

You can't directly perform this check via one bitcoin core RPC call, you would have to write a script of some sort to perform the 3 checks to figure out which type of input you were given. You can first check for a valid block hash using the getblock RPC, and if that failed you know its not a block hash. Next you would have to have txindex enabled on your node to allow yourself to query txids using the gettransaction / getrawtransaction RPCs (because by default the node only indexs transactions which are related to your wallet). And then to check if its a valid address, you can use the validateaddress RPC call. If all of those failed, you know the input is invalid.


How likely is it that all the addresses involved in a SINGLE multisig transaction input/output belong to the same wallet/owner?

Multisig is useful for both a single individual and for a group. Individuals can use it to secure their funds by using a 2/3 address and distributing the keys. Groups can use multisig to implement an escrow transaction for goods or services.

These, and other use-cases, for multisig are being used today, but it's impossible to know the proportion of individual-use and group-use. There is no way to know for certain if they are controlled by the same person, unless you have more information than just what is available in the blockchain.


How do you know that your private key has been stolen?

If your private key was stolen, then the thief can provide you with definitive proof that he possesses the key---for example, by spending your funds.

But unless you have such proof, all you can do is guess whether your private key has been stolen.  There's no definitive way to prove that your key hasn't been stolen.

Usually, if you have enough evidence to worry that your key has been stolen, it's a good idea to take the steps you would take if you knew it was stolen.  For example, generate a new safe private key and address, and use your old private key to send funds to the new safe address.  That way your money is safe whether or not your old private key was stolen.


The Legit & Safe—Windows Command Line Miner

There are no official CGMiner binaries being distributed anymore specifically because of this problem. You will need to download the source code and compile it yourself. Instructions for doing that are available here.

The reason that CGMiner is flagged as Unsafe is due to Anti-Virus software and malware that use CGMiner. Anti-Virus have performed analyses of the CGMiner and determined it to be a cryptocurrency mining software - which it is. Unfortunately, a lot of malware are also capable of mining cryptocurrencies once they infect someone's computer, so AVs have taken to flagging everything that can mine cryptocurrencies as unsafe. This then reaches the browsers which do the same.


Can i still use the old address to recieve Bitcoin with Bitcoin.com Wallet

I tried Cloud Minning recently

Cloud mining services are scams generally

Are there any legitimate cloud mining services?
Is a cloud mining subscription worth it?
Cloud mining questions

I accidentally press the change address button, will my account still able to receive Bitcoin?

Yes. Addresses can receive multiple payments. Addresses never expire.

Address reuse questions

Address re-use is only a privacy concern and probably only a concern if you have several different people sending money to the same address or if you then pay multiple parties with funds previously received at one address.
You mention the Bitcoin.com wallet - I'm not familiar with it. If it is a custodial wallet then you'd need to contact Bitcoin.com support to ask if they have any problems associating your account with re-used addresses they have generated for you. This is because sometimes services call an account a wallet when it isn't a normal Bitcoin wallet and its up to each such business how they choose to associate addresses with customers' accounts. I'd be surprised if it was a problem but you'd have to ask to be certain. Remember that Bitcoin.com is to Bitcoin as Dollar.com is to the US Dollar - the businesses are unrelated to the currency except as users of it.

is bitcoinonlinepool.com a legit or spam

How to tell if a cryptocurrency exchange or trading platform is trustworthy?


Corrupted old bitcoin wallet. !!!file unknown has LSN!

how i go more deeper in this to get those private keys and addresses?

Well the basic process I would start with would be

Don't use the computer that contains the damaged file
Use a bootable USB to make a copy of the file onto external media
Lock the computer away until you have repaired the file or extracted keys on a new computer
make copies of the damaged file and work only on those copies.
keep some unaltered copies in some safe places.
make a hex dump of the wallet.dat file
study the defined file format used by Bitcoin core in 2013

perhaps by searching for documentation of the file format.
perhaps by studying the source of PyWallet.
perhaps by getting a 2013 set of Bitcoin-core's source code from GitHub.

compare the defined file format with a hex dump of a working wallet.dat of 2013
make small changes to a working 2013 wallet.dat, make new hex dumps and study the differences.
compare the defined file format with a hex dump of your damaged wallet.dat
attempt repair
perform some forensic recovery process of all data in unallocated space on a bitwise copy of the original computer's hard disk(s) or equivalents. Repeat process on data to try to identify fragments of wallet.dat data.

This would be slow difficult work. You will find differences that don't make sense and you may have to invent new content to insert and also decide what parts to delete. You may need to find tools, or create tools, that allow you to make the changes to a copy of the wallet.dat to repair it. Or you may be able to identify the private keys in the hex dump and just extract those.
If the wallet contains a small amount I wouldn't bother. If it contains an amount equivalent to a years wages say - then, in your shoes, I would probably spend some time on this.

There's no safe way to have someone else work on this. It's easy for a stranger to say they found nothing and walk off with your wallet's money. It's easy for conmen to slowly gain your trust until you pay them various fees for working on this for you.


How would I generate a valid vanity address for destroying coins?

You can do this manually using the hex/base58check converter (such as the converter on brainwallet.org)

Remove the starting 1 and convert from base58 XXXXXXXXXXXXXXXXXXXXXXXXXXX to hex: 25c7415deb828c49ccb799c452ae17589bca1af2 (make sure result is 24 bytes)
Remove last 4 bytes to get a 20-byte hash:
25c7415deb828c49ccb799c452ae17589bca1af2 -> 25c7415deb828c49ccb799c452ae1758
Convert from hex 25c7415deb828c49ccb799c452ae1758 to base58check: 1XXXXXXXXXXXXXXXXXXXXXYDgWVE

Final result is valid 1XXXXXXXXXXXXXXXXXXXXXYDgWVE


Probability an honest node finds the next block vs. probability the attacker finds the next block

No one has an upper hand in this process. So shouldn't p and q be equal to each other?

The chances of finding a valid block header that meets the target requirement increases proportionally to the number of tries. This means that it is proportional to the hash power that you have. Even if there are two miners, one could be using a huge datacenter (the size of United States), while the other might be mining on his 10 year old laptop. Their hash power would not be the same, and hence p and q will also not be equal to one another. Hash rate is the metric to be used to find out the probability of a miner finding the next block.

  Then all an attacker needs to do is to form a pool whose compute power is greater than max(p_i). Am I missing something? In other words, the pool with max compute power can attack the blockchain already.

What you are describing is a 51% attack. With the current hashrate of the Bitcoin network, it would require HUGE investments (billions of dollars) from the entity who is planning to do such attacks. At that investment level, the economic incentive to launch such attacks may be tiny, unless it's a state actor who is trying to annihilate the confidence of the network. Even if a fraudulent miner amasses >50% of the hash rate of the network, full nodes MAY try to patch themselves to reject such blocks (for example: if that attacker tries to broadcast a longest chain that is > 6 blocks different than the original chain, to prevent double spends).


AltCoins based on Scrypt - How to do transactions with PHP?

I have a library in PHP for bitcoin transactions - https://github.com/Bit-Wasp/bitcoin-lib-php. It's mainly focussed on Bitcoin, and there are one or two places where hardcoded constants make dealing with altcoins tricky. That said, they are minor parts of the code.

(Only thing that comes to mind is if you're generating private keys just make sure you encode them to WIF's using BitcoinLib::base58_encode_checksum('privkey byte' . 'privkey hex'), passing the respective private key version byte, as the library will DEFAULT to using [address byte]+0x80 when generating addresses. This is how bitcoin does it, but it's not compatible with some coins, because they just use the first hex which gives the prefix they want)


I am not sure that I understood the question well. Would that be correct:

I transfered from some exchange my funds to an address, which I imported as watch address on blockchain.info. Now I see funds but I can not spend it, what should I do?

If that questions is the same what is asked and user reports that blockchain.info has not helped at all, then I would assume that blockchain.info is not the owner of the address that was imported. Here is what you could do:

To which address did you send your funds? If it is address that you somehow created with some application like bitcoin core, multibit, .... , then their application/user data folder must be still present on your pc (even if you uninstalled it). If that is the case and a wallet address you sent funds too is in ie. bitcoin core, you can export your private key if you write in the console dumpprivkey YourBtcAddress
If you imported exchange's wallet address, then funds would be still visible on exchange. In that case exchange would still have your coins and could help you
If this address has never belonged to you, then you do not have the private key and you can not do anything beside to contact the owner of the address.
Bruteforce is not really a option, but in theory it is possible. However, this is a point that you actually should forget.

I hope it helps. I see here only 3 possibilities, address belongs to you (you can retrieve your funds), address belongs to exchange (you still could get your funds) and that it belongs to somebody you do not know and you have no private key (in that case you can not do anything to get your funds back), maybe you could ask on internet who is the owner but I doubt any repl will come.


Where can I store a Bitcoin Wallet Safely?

Here is an in-depth article that explains the steps you should take to secure your wallet. https://en.bitcoin.it/wiki/Securing_your_wallet.


If everyone has a copy of the block chain, how much space does it take?

I run a full node, and as of today, the blockchain is 10.1 GB.  Since the bitcoin network is active, the answer to your question about how big the blockchain is something that is quite time dependent.  If you were to come back in a month and ask the question, the answer would likely be 11 GB.

I was wondering a while back about the size of the blockchain and whether or not it would eventually consume my entire hard drive and I crunched some numbers and calculated that if I expect my computer to last another three years (it's two years old now), the blockchain would then be 60 GB.  I have a 250 GB hard drive and with the amount of free space on it (141 GB), even when it gets that big, I should still have plenty of free space.

Nothing really prevents the blockchains from growing so big that we would run out of space, but given that Moore's Law applies to hard drives as well as processors, I'm not all that concerned about this happening.  By the time the blockchain will be in danger of consuming my whole hard drive, my computer will be old enough that I'll likely need a new one anyway.

However, if this is something that you're concerned about, you always have the option of using a lite weight client like Electrum that does not require you storing the blockchain on your hard drive.  Electrum is available at http://electrum.org/

In any case, most people these days have enough storage space to store the blockchain.  The bigger bottleneck is that bitcoin-qt is a bandwidth hog and bandwidth tends to be a lot more precious than hard drive space so if you are using a relatively low bandwidth internet connection, this would be another reason to use a bitcoin client that does not require that you run as a full node and relay transactions such as Electrum.


The API call you are looking for is the market depth:

https://btc-e.com/api/2/btc_usd/depth

There are also calls for LTC/BTC

https://btc-e.com/api/2/ltc_btc/depth

and LTC/USD

https://btc-e.com/api/2/ltc_usd/depth

All of the above return JSON data including both ASKS and BIDS


It is not enough to check the merkle tree, as this says absolutely nothing about the validity of the contents of the block, just that somebody was able to follow the protocol up until that point. If a transaction say, created money out of nowhere, this would not be caught by simply looking at the existence of a transaction in a block.

To correctly validate a block a node must do the following low-cost checks:

format of the header is correct
rules about timestamps and difficulty are followed
the proof of work matches what is required

Assuming these rules pass, they must do the following high-cost checks:

the merkle tree is correct and matches the root in the header
no outputs are spent which do not exist (or have already been spent)
the values in every transaction input and output don't create money
that every script execution is successful and does not end in an error
that every ECDSA signature is valid
that misc rules such as size, format of script, and total block size are not exceeded

Most of these are CPU intensive, such as doing potentially hundreds of thousands of ECDSA, SHA256, and RIPME160 operations. Some are IO intensive, such as validating previous transaction entries if these are not already in the cache. None of these operations are exponential in cost with the number of transactions, but they need to be completed quickly to maintain consensus on the network.

Much of this work can be done ahead of time, an unconfirmed transaction can have many checks against it done, so when it arrives confirmed inside a block the validation is cached. However we can't assume this is always the case, as the Bitcoin network needs to be able to operate in adversarial conditions, such as a miner creating a block with a large number of otherwise unseen transactions.

We also need to consider that every block needs to be validated by nodes which are newly joining the network, and the cumulative cost should not be excessive to process. The historical chain at this point takes many hours or even days to validate on low-cost hardware, and we of course shouldn't be changing behavior in such a way that this cost grows more quickly.

That said, the Bitcoin network frequently has blocks above 1MB today, often exceeding 2.2MB.


How do I verify an address with GPG and Sign a bitcoin txid with a sending key as proof I sent bitcoin?

1.) While I was reading the message I saw the text below saying to "verify each address, line and signature." How would one go about verifying these?

Your Bitcoin wallet software should have an option to verify a message. For example, in Bitcoin Core, you go to File > Verify Message and a dialog appears where you can enter the address, message and signature. In whatever verify message window, enter the address, message (the line containing the address, email, and date), and signature (the line after the address). Then click "Verify". The software will then check whether the signature verifies.

If the signature does verify, this means that the owner of the private key for that address actually made the statement that is the message AND that the message was not tampered with in any way.

  2.) If I were to send some bitcoins to the Free Software Foundation and would like for them to know they came from me, I would have to provide some sort of proof. The following excerpt from the message says how to do this; however, I still do not quite understand how to execute this:

When you send Bitcoin to someone, your transaction will "send from" some addresses (it doesn't actually send from any addresses, that's now how Bitcoin work). If you look at the transaction details in a block explorer, you will see something labeled as the inputs and a list of addresses. Those addresses are what are referred to on the website as "sending keys". Those addresses should all be from your wallet.

So what you should do is get the transaction ID of the transaction, find an address that is listed as one of the inputs of the transaction, and then use your wallet software to sign a message (the txid) with that address. You then email that message, the address you signed it with, and the signature, to the FSF. Your signed message can be more than just the txid, it can have any text that you want so you can include things like your name, mailing address, and contribution info.

  3.) I used Gpg4win to verify the whole message by importing John Sullivan's GPG public key from here and clicking the "Verify" button. But how does this work and what purpose does the PGP signature at the bottom of the message serve?

The PGP signature does two things: it proves that the owner ofthe PGP key (John Sullivan) actually made that statement (or at least knows of its existence) and it verifies that the statement itself was not tampered with.

This verification, combined with verifying the address and it's signature earlier, prove that John Sullivan has control over those addresses (because he provided a signature with those addresses and he signed both the addresses and their signatures with his own PGP key). Thus if you send Bitcoin to that address, John will receive the Bitcoin.

For more and better info on what a signature means, I suggest you read the wikipedia page on Digital Signatures.


How secure is using TOR in Lightning Network?

The paper you link to when used as advice rather than a scholarly investigation into the tradeoffs of different choices is outright bad advice.

The attacks they give are largely generic and have little to do with tor itself, while use of tor provides non-trivial protection against many other vectors, and if used consistently and exclusively at least prevents linking the users network identifiers with their activity. Almost every security decision is an exercise in tradeoffs when it comes to advice you cannot just consider the risks of one option while pretending the alternatives are riskless.

Moreover, its not uncommon to see this article breathlessly promoted on the same pages that recommend users use lite wallets that simply send all their addresses to remote hosts-- effectively always operating under the worst case possibility the article suggests. If using tor is a bad idea then using, say electrum, is "holy crap why would you ever do that?!" -- yet you don't see that level of promotion against using electrum or similar.

Given the recent rise in promoting it I am concerned that some parties might be sharing it with the express intention of undermining user privacy.


btc transaction stuck from last 3 days on blockchain

Looks like you put a very small fee for the transaction. As the mempool is pretty cluttered your transaction may take quite some time to pass through. Did you send your BTC from a platform?

Check the mempool here:
https://jochen-hoenicke.de/queue/#all


It's possible! But it's complicated :]
The main reason is block.io are using multisig addresses, meaning that it's not the usual address that you can redeem funds with only one private key, but here we require two private keys to sign every transaction.

EDIT - This solution used to work for some time, but it doesn't work at the moment

It seems that blockdozer.com changed their API and their AJAX/CORS policy in some way that makes it impossible to query outputs and to submit transactions. I was able to overcome their AJAX by disabling security on the browser, however the raw transaction that's being generated contains special characters such as "|" and the API doesn't support that. It did work about a month ago though, but not any more

Since Ik'm no expert on this I submitted a comment to the developer that implemented bitcoin cash support in Coinb.in, I'll update here once I get a response. Here's the PR and comment in Github:

https://github.com/OutCast3k/coinbin/pull/113

Phase one - Acquire your private keys

First phase is to your private keys from Block.io - Log into your wallet, go to "Settings", then press "Private Key Access". You'll get an email with instructions how to proceed. At the end of this process you should have a file that contains something like this :

* Address: 3ET4FuXvHahN4WwrJ3dyCLsoVbDVZtVEUU
* Address Type: P2SH
* Required Signatures: 2
* Redeem Script: ....
* Redeem HEX: 5221039960aa771270362b7e49400433e103c59e12c6a43a946d4b048f7efcc68bc0bf21028825d729387c6b0aafae1c47802c62d7f965de1800d6122143c681044c50700452ae
* Public Keys: ["039960aa771270362b7e49400433e103c59e12c6a43a946d4b048f7efcc68bc0bf","028825d729387c6b0aafae1c47802c62d7f965de1800d6122143c681044c507004"]
* Private Keys: ["KyubGochD3MkXW4KkT95K6FXbZSrtHg6creF6xaRDc9C3qkyidza","KxFLJ2n76i2W9WB2YdJd1zCL2Kmgpk1vfB2XEynSpQWsYCe4bfqn"]

Phase two - coinb.in

I tried to do it the easy way using Electron Cash - there's an option there to import multi sig addresses but it doesn't work. I had to sign the transaction manually and broadcast it to the BCH main network. coinb.in is an awesome tool to do that, however at the moment the pull request for using BCH isn't merged yet, I deployed a version of the tool here :

http://galed.codus.net/coinbin/

Alternatively, If you want to be extra cautious you can run the tool on your local machine by running these commands :

git clone https://github.com/dabura667/coinbin.git
cd coinbin
git checkout bitcoincash
open index.html

Phase three - signing a transaction and braodcasting

PLEASE PLEASE PLEASE WATCH THE INSTRUCTIONS in this youtube video to get a better sense of what needs to happen: https://www.youtube.com/watch?v=oUSVmLegj8k - If you're dealing with large sums of BCH you could end up losing everything, so please be careful!

The one difference is that you need to be careful to choose the bitcoin cash network, otherwise you'll be broadcasting transactions on the BTC network:

Click New -> Transaction
Enter the redeem HEX that you received from block.io in the first box (Address, WIF key or Redeem Script)
Click on "Advanced options" and change the network to "Bitcoin Cash mainnet"
Put in the amount you want to transfer and the address, make sure that the fee is not too high
Click submit, you will get a long HEX string. copy it
Go to "Sign" , paste the string, paste the first private key from the file that block.io sent you, click "Submit", Copy the string
Paste the string into the second box, copy paste the second private key from the block.io file, click Submit, copy the output
Go to "Broadcast", paste the string and submit.


July 2015 forks and SPV mining: Why did F2Pool and AntPool mine an unverfied chain for so long?

It seems that F2Pool implemented their version of SPV mining with insufficient thought to the effects it would have. The proof is right there in the blockchain: they they didn't implement a timeout.

It was a financially expensive mistake, but miners are highly incentivized to decrease latency, so not implementing SPV mining would also have cost them money.


A bitcoin private key is a number greater than or equal to 1 and less than X, where:

X = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

That's in base 16. In normal base 10 numbers, that's:

X = 115792089237316195423570985008687907852837564279074904382605163141518161494337

Any number outside of that range is an invalid private key. That includes 0 and X, X+1, X+2, ...


Why aren't Bitcoin transactions processed and verified by normal Bitcoin clients?

Transactions are in fact verified by every network node (computer running bitcoin-qt). A transaction which is not valid will not be propagated and the client will not display it to the user as a payment.

However, a transaction being valid doesn't mean there are no contradicting transactions. What miners do is synchronize the transactions using proof of work as a signal.


(Bitcoin Core, recovering my wallet) problem finding the address I sent coins to in Bitcoin Core 0.11.2

First you need to backup your wallet.dat file. Then, since your installation is from a while ago, I would recommend reinstalling bitcoin, and then importing your wallet.dat.

Backup wallet.dat

To copy your wallet.dat on a Mac:

Cmd+Space then type terminal

In terminal type:

cp ~/Library/Application Support/Bitcoin/wallet.dat ~/Desktop

I would recommend also backing up a copy to another computer or disk drive.

Install Bitcoin-core

Download and open .dmg file from bitcoin.org, and follow installation instructions.

Restore wallet.dat

To copy your wallet.dat back on a Mac:

Cmd+Space then type terminal

In terminal type:

cp ~/Desktop/wallet.dat ~/Library/Application Support/Bitcoin/

Then you can export your key to whatever wallet you want.


These values appear for the regtest chain only.

It looks like these values are supposed to state the time window during which deployment of a particular protocol change is allowed to happen. For regtest that window is set to be from times 0 to 999999999999, maybe so that you can do it whenever you want.

For your coin, you presumably either want these features active from day 1, or not at all. In either case you'll probably want to remove the time-deployment code altogether.


Coming from this question, is there any comprehensive collection of what errors can each RPC command return?
For example. Let's say I want to run getbestblockhash or getblockcount. I'm unsure about what errors to expect.

I don't think that such documentation  exists. You would have to read the source code for a particular RPC. Additionally, since some functions are shared between RPCs and can return specific errors, it may not be easy to enumerate all of the errors.

Furthermore, I'm unsure if there's a generic error code that can be return in many cases (RPC_MISC_ERROR for example).

If there's an error which doesn't have its own specific catching and checking (i.e. an exception is thrown that the RPC doesn't catch), then RPC_MISC_ERROR will be returned.


If you were getting transaction notifications to your email address, you might be able to find something in your mail account. Other than that, an address alone does not provide any indication which service or software might have generated it.


At what point does the criminal get caught?

Most sites that sell Bitcoin for cash require more information than just "bank info" in order to run the transaction.  So the scenario you outlined is not quite complete for the purposes of "not getting caught".


do i need to fully download the blockchain before operating commands on litecoin daemon or dash daemon

I figured out we only need to sync to download new transactions rest we can add listen=0 to keep band-with minimum and continue as usual without contributing.

transactions anyway are broadcasted by node and will be visible in the network.


Send bitcoin with bitcoin core without syncing to network

A fully synced Bitcoin node is the only way to know without trust that the coins you think you own are really yours. Otherwise, someone can trick you into thinking you have money you don't. You can try to spend the counterfeit coins, but the network will reject your transaction.

If disk space is your primary concern you can run your node with pruning active, which deletes old blocks from disk but maintains a complete UTXO set, which is all you need for full validation.

If bandwidth or CPU is your primary concern, you can investigate the SPV and Neutrino models, which compromise privacy and security in varying degrees for convenience.

Finally, and this is not recommended, but you can trust someone to run a full node for you and provide you with the minimal amount of data you need to create a transaction which you can then sign and broadcast locally. This can be done (for example) by requesting transaction data from Blockstream's esplora API and you can see an example of such a construction in my (novelty-only-do-not-use-for-real) brainwallet sweeper application: https://github.com/pinheadmz/brainsweeper


You can find your answer here

Snippet of code

Example from bitcointalk

    <?php
  #Below is full list of available characters.
  #"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
  $fp=fopen("/dev/urandom","r") or die;
  $available_chars="23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz";
  do{
    $minikey='S';
    for($i=0;$i<29;$i++){
      while(($c=ord(fgetc($fp)))>=strlen($available_chars));
      $minikey.=substr($available_chars,$c,1);
    }
    $check=hash('sha256',$minikey . '?') . "\n";
  }while(substr($check,0,2)!='00');
  fclose($fp);
  $priv=hash('sha256',$minikey);
  print "Minikey: $minikey\n";
  print "Privkey: $priv\n";
?>

You can find some useful information here


Where does bitcoin-qt store it's initial settings

Bitcoin-Qt stores its own modifiable settings outside of bitcoin.conf (which is intended to only be read).

The location and format of that file is platform dependent, but on Linux it is ~/.config/Bitcoin/Bitcoin-Qt.conf.


Is Bitcoin still an experiment?

I don't think so. There's no control, and nobody's made one of those three panel boards.

In all seriousness, though, I think Satoshi probably wrote and published Bitcoin because he found it interesting. He may also have done so because it aligned with his political views. Of course, we're speculating on the motives of a guy that nobody's met.

I also speculate that the current Bitcoin developers are part of the project for much the same reason.

  When does the test end? Who declares the end of the experiment?

Anybody could declare it, I suppose. It would be a bit like Emperor Norton ordering the US Army to arrest the United Nations, but they could still declare it.

  As we're nearing the end of 2014 and getting closer to the fifth birthday of Bitcoin, is it still an experiment?

I think the essence of your question is, "Is Bitcoin ready for mainstream adoption?" I don't think so. There's aren't mature payment solutions for physical stores. There are problems with Bitcoin that haven't been sufficiently solved to my mind (primarily detecting double spending).


How to make more than 1 nodes of mine connect each other?

You can add them to each other nodes bitcoin config file. If you want to connect to a specific node among others, use addnode=IP:PORT in your config. If you'd like to only connect to your own nodes and not other nodes on the network, you can use connect instead of addnode, but of course you should have at least one outgoing connection to get blocks, etc :)


Are pseudo-random number generation algorithms good enough to cover all possible Bitcoin addresses?

There are plenty of PRNG algorithms that are good enough. You just run into trouble when you, through ignorance or error, pick one that isn't.

The simplest adequate solution is to gather enough information, from any source and of any size, to ensure that it has at least 160 bits that are unpredictable by any attacker. You can then SHA256 hash this data. You may need to gather a large amount of data to ensure it has sufficient unpredictable bits, but that's okay.

You can make things a bit more secure by hashing many, many times or using a memory hard hashing algorithm. That way, an attacker that can guess some of your bits has to go to much more effort to try random combinations of the ones he can't predict to try to replicate your key.

If you don't have access to sufficient unpredictable data, from any source, then there's not much you can do. Your security is only as good as the unpredictable input your PRNG has.


How to obtain trades from the websocket transaction feed?

For a program (a client, a charting site, a simple order book display, etc) to efficiently track changes it can subscribe to a stream of transactions related to just what it's interested in, a set of accounts, a set of order books, etc. Alternatively a system can subscribe to all transactions or fetch individual closed ledgers and their associated transactions.

Whatever way a program gets transactions, each transaction includes a set of meta data describing all the changes it made within the ledger that included it. For any transaction that executes any part of a trade offer it will included meta data that references the trade offer, and describes how it is changed (how much is consumed, if the offer is to be removed, etc).

Here is an example recent transaction with meta data. These can easily be looked at via a site like https://ripple.com/tools/info/ or https://ripple.com/tools/api/

{
  Account : "rGTfnwAqmPG5CN9vgzfubDQA4CkCpeK9zZ",
  Amount : { /* currency, issuer, ... */ },
  Destination : "rMDnTSD3TUizf2qvd9oGdCz3BXLheJyYtP",
  Fee : "15",
  Flags : 0,
  LastLedgerSequence : 6005165,
  Paths : [ /* 3 items */ ],
  SendMax : { /* currency, issuer, ... */ },
  Sequence : 3539,
  SigningPubKey : "02A25443D8FC411A395B626760062F506BF44FDA7CBFE004B1F2A7D2052CCEBC33",
  TransactionType : "Payment",
  TxnSignature : "3046022100D806A3FF5F2002F55BA48C4824CF8AEC70741411383CD79037012A85C3F92A9502210084335505CA91F28DDE04290FB7A46318F6337E2522D46731403BE686176F3A12",
  hash : "14A60155B276A78ED29FF11A9EE8E63AC1FCBED50CCE1AB30642B06E8D0E00D8",
  inLedger : 6005158,
  ledger_index : 6005158,
  meta : {
        AffectedNodes : [
              {
                    ModifiedNode : {
                          FinalFields : {
                                Account : "rH1hbPUfvhmqkEE3AWi77CZNexJyTGE6SF",
                                BookDirectory : "4627DFFCFF8B5A265EDBD8AE8C14A52325DBFEDAF4F5C32E5D04F0F1A6DD3F05",
                                BookNode : "0000000000000000",
                                Flags : 0,
                                OwnerNode : "0000000000000000",
                                Sequence : 71,
                                TakerGets : {
                                      currency : "USD",
                                      issuer : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
                                      value : "221.8195734530501"
                                },
                                TakerPays : "30851122872"
                          },
                          LedgerEntryType : "Offer",
                          LedgerIndex : "0346EED5470F7A69B0A8DBF4B403DDD5CFD80F4A588555A934F00B09B4CE7AD2",
                          PreviousFields : {
                                TakerGets : {
                                      currency : "USD",
                                      issuer : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
                                      value : "222.82157345305"
                                },
                                TakerPays : "30990483095"
                          },
                          PreviousTxnID : "B8613D4BE0C6EAA9F970CC2D580534B8A2B53F1BD844518BED4A73AA0FA52DFB",
                          PreviousTxnLgrSeq : 6005141
                    }
              },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* DeletedNode */ },
              { /* ModifiedNode */ },
              { /* DeletedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ },
              { /* ModifiedNode */ }
        ],
        TransactionIndex : 0,
        TransactionResult : "tesSUCCESS"
  },
  validated : true
}

In this example, you can see that the transaction happens to be of type Payment but it modified a node with LedgerEntryType: offer. Those are what you'd look for (from any and all transaction types, "OfferCreate", "OfferCancel", "Payment", etc). Fields such as "BookDirectory" are mostly for internally finding the node with the ledger, a simple tool processing these JSON blobs could just look at the Account and Sequence fields to uniquely identify a specific offer. In this example the there is both a final TakerGets/TakerPays fields as well as previous; subtracting tells you how much of the offer was taken. (Such fields without a listed currency/issuer pair are XRP in drops, divide by 1e6 to get the amount of XRP.)

If a payment or crossing offer were to fully consume an existing offer, then you'd see a "DeletedNode" entry for it and would again need to use the previous/final fields to see how much of the offer was consumed (which could be zero if the offer was removed for other reasons, such as no longer funded or expired).

If you're trying to assemble all the ways a specific offer has changed through it's life you can track backwards via either the PreviousTxnID or the PreviousTxnLgrSeq fields.


Is it fraud? Would banks ask for fees through bitcoin?

This is definitely a scam.

Even if an activation fee was a legitimate thing, they would just charge that amount out of the amount you were going to receive - if you were to receive $1000 and the fee was $5, they'd just give you $995. Beyond that, no bank I'm aware of charges fees in cryptocurrencies.

Don't send any money to these people.


Is there a list of countries that are not likely to persecute bitcoin businesses?

One possible location would be Nowhereisland - a new nation born from an arts project. It is extremely liberal in it's views and is still in formation.


how the buy and sell will be going to happen

The canonical process for buying Bitcoin with a different currency is

The buyer uses their Bitcoin wallet to create a receiving address.
The buyer communicates this address to the seller.
For example the buyer's wallet creates a QR-code (2d barcode) from the
address and the seller scans the barcode.
The seller uses their wallet to create a draft Bitcoin transaction that
sends an
amount of Bitcoin using unspent coins from their wallet to the Bitcoin-address
provided by the buyer. This involves a cryptographic signature made by the
seller that proves they have the right to spend those coins. It also locks the
output amount with a Bitcoin script that similarly requires
the use of recipient's private-key to spend.
The seller's wallet transmits the draft transaction to a few nearby
Bitcoin nodes
(e.g. other wallets, etc)
Other nodes pass the draft transaction to other nodes.
Eventually the draft transaction reaches miners who each add it to their
pool of draft transactions.
Eventually one of the miners, adds that draft transaction to a block template,
usually along with a lot of other unrelated draft transactions
from their pool. The miner starts mining the block.
eventually a miner succeeds in mining a block that includes the
draft transaction.
The miner transmits the new block to nearby nodes
Other nodes see the block is valid (matches Bitcoin's rules) and pass it on
Eventually the buyer's wallet sees the new block,
adds it to their copy of the blockchain and
adds the value to the wallet's "balance".
Over time, other unrelated blocks are added to the blockchain.
each of these subsequent blocks counts as one confirmation of the
transaction. Six confirmations is generally taken as certain.
Some people choose to accept fewer confirmations as certain.

i.e. Which block will make the transaction happen

Any subsequent valid block which contains the transaction.

and is there an automated process for it?

The first three steps described above normally involve some human interaction (but can be automated using software APIs). The remaining steps are fully automatic.


Trying to find this answer myself.  Noticed that the stratum_proxy is written in python and thus has the answer we are looking for.
https://github.com/slush0/stratum-mining-proxy/blob/master/mining_libs/midstate.py


How much will difficulty increase when ASIC miners become generally availible in the coming months?

I'm guessing this has now been asked like a million times.  Exponentially at first - once hw is available and it becomes more mainstream for the average person to buy asic hardware and setup at their own house...we will see difficulty plateau at a steady rate.  However by the time the plateau occurs, most 50GH/s hardware will only be able to mine a few USD a month...people will have already shifted over to alt-coins and GPUs will be targeting Scrypt Related stuff by that point.  I think we will see a shift of asic hardware from smaller groups  being used on other sha256 altcoins such as PPC, TRC, and FRC.

I predict Difficulty will hit 120 Million by December 300 Million by June and 1 billion by Dec 2014 at the next block reward halving event.  This won't be because of the small guys I mentioned in the prior paragraph either...difficulty will steadily rise and plateau because there will be dozens if not hundereds of commercial medium and large scale mining operations that came online to 'milk' the system.


The P2WPKH actually uses the HASH160 hashing algorithm, which is just RIPEMD160(SHA256(pubkey)).

The reason for using SHA256 is mentioned in BIP141:

  The increased size improves security against possible collision
  attacks, as 2^80 work is not infeasible anymore (By the end of 2015,
  2^84 hashes have been calculated in Bitcoin mining since the creation
  of Bitcoin). - BIP141

And yes, like you said, the witness program is determined not only by the version 0x00 byte, but also the length of the program. See BIP141 - P2SH


Bitcoin -qt or Bitcoind - which one to use for building a trading website?

You should use bitcoind. You can make JSON RPC calls to it to generate an address, or to find out what the balance of an account is. Using that, you could build an application that allows access to a song if a customer pays for the song, or something like that.


Retrieving Old Transaction in Bitcoin Core's console -getrawtransactions returns "no such mempool transaction" error

You're trying to use an optional feature of Bitcoin Core: the ability to query for old transactions.
This functionality needs:

(a) the full blockchain (where else would it get the transaction from)
(b) an index by txid so it doesn't need to read through 270 GB to find what you're looking for.

The error message you get is telling you that this (b) index is not enabled. When you try to enable it, it fails because you don't actually have the blockchain (a) in the first place (it's pruned), so it can't be indexed.
If you really need this functionality, you'll need to disable pruning, start syncing from scratch (as it'll need to download the blockchain again), and enable indexing.
However, you saying "tried to verify" perhaps highlights a misconception you have: getrawtransaction doesn't verify anything, it just retrieves the transaction in your local copy of the blockchain. Everything is already verified, even when it's not kept on disk. Generally when you care about a particular transaction, it's because it directly or indirectly affects your own funds, and the recommended solution for that is simply using good wallet software - it will only show you transactions that are verified and whose entire history is verified.


The path you pass to dumpwallet is the filename of the dump.

If you pass the name of your wallet database itself (or any existing file, actually), it will get overwritten.


HD wallet getting every time diffrent derivedPrivatekey from same derivation path

You have the data and network arguments swapped when you create the hdPrivateKey, see Private Key | Bitcore. Try this:

var bitcore = require('bitcore-lib');
var DerivationPath = "m/44'/145'/0'/0"
var hdPrivateKey = new bitcore.HDPrivateKey('xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi', 'testnet');
var orderPrivateKey  = hdPrivateKey.derive(DerivationPath).privateKey;
var Address = orderPrivateKey.toAddress().toString();
console.log('Address: ' + Address);


The commands are listed on the bcoin GitHub wiki

The command you are looking for is
bcoin wallet watch [address]


Bitcoin core full node - Should I choose my peers or it's fine to use the hardcoded ones?

The list is just for bootstrapping, no need to manually list peers unless you have others you specifically want to maintain connectivity with.


How does mining work on the moving target (variables change every second)?

Realistic miners run through all 2^32 possible nonces in much less than a second.

If a transaction occurred after you started your nonce search, then your block won't include that transaction. There's no problem with that.

If the time changed after you mined your block, then your block won't have the exact right time. Again, no problem with that.

And if you think about it, there can't be any problem with that. How would anyone know when you mined the block or whether the transaction occurred before or after you mined the block? It's mining that allows bitcoin to agree on these things, so if you mined the block, you're the one who gets to choose.


At the time of the question being posted, Coinbase was paying your transfer fees. Starting on March 21st 2017, they stopped paying the transfer fee and the user now pays the fee.
Coinbase has blog post about it here:
https://blog.coinbase.com/coinbase-spring-cleaning-4f27710ff821#.b8hzpa2hb


Assuming that the BTC price is falling against USD, either BTC/LTC will remain stable and LTC will crash proportionately against USD or LTC/USD will remain stable and BTC will crash against LTC or something in between.  Otherwise, there will be arbitrage opportunities by changing by using LTC as an intermediary between BTC and USD


this transaction spends an input which is unconfirmed ~ 2 hours now

Looks like it was included in block #441,569 and currently has 126 confirmations.


Current block vs whole block chain attack

Changing the blockchain at a point earlier than the most recent checkpoint is impossible, at least with the main client. It won't be accepted by those clients.

One can fork the chain at any point, but the most current block is the easiest as it does not require to backtrack and solve the previous blocks. Unless you have some specific transactions you want to invalidate, you would start from the current block.


The first three scenarios are indeed possible, the last one is identical to the second.

This is called a collaborative close. It has the advantage of using a lower on-chain fee since the transactions are not time critical and the users get their coins back immediately (no dispute time).
If the other node is unresponsive (offline or doesn't sign a collaborative close), you can do a unilateral close. The downside of a unilateral close is that the closing party will have their funds unavailable until the dispute is settled (usually about 24 hours) and higher fees are leveraged since this is a pre-signed transaction that is time-critical to get confirmed.
This is called a breach-attempt, and is the reason for the dispute period above. The breach is basically publishing an old unilateral close transaction, and it needs to give the counterparty time to react and punish the breaching party.

So in all cases well-behaved parties get their funds back, the difference is just in how long it takes.


Understanding SPV, pruning and its downsides, as well

So, as I understand, an SPV client just receives the latest merkle root of the latest block and verify if a transaction is in it. It then see that very much hashpower was wasted on that block, and then assumes that it should be a valid block. Am I right?

No. A SPV client submits a bloom filter to a full node providing SPV services. Each time a block header is sent to you, a full node will check against said bloom filter is transactions that you may or may not be interested is in the block.

If yes, then said transactions will be included, including all other transactions required to compute the Merkle Root. Otherwise, you just receive a block header with no transactions whatsoever. For each block header received, your SPV client will check if it contains a proof of work solution that meets the difficulty requirement and if it is linked to the previous block (as usual).

  In pruning mode, however, the entire blockchain is downloaded, verified, and then pruned. Now, the client just downloads new blocks, verifies them, and prunes them. As I've read, however, in pruning mode, the client maintains the latest x blocks for some reason. Why?

I assume you are talking in terms of a full node, since SPV nodes do not download the blockchain at all and there's nothing to prune.

The reason why the last N blocks are kept is so that when a re-organisation takes place, it is possible to systematically undo transactions that led to the current UTXO set which is based off an orphaned chain. You then undo to the point where the new succeeding chain begins and apply transactions recorded in the new chain. Without the last N blocks, there's no way to un-wind when chain re-org takes place, then to re-derive the UTXO independently requires a full download of the blockchain.

  Also, if I have the entire blockchain in pruned mode, that is, a blockchain made of only merkle trees, given a new transaction and its merkle path, I can verify that it's in some block and I know that this block is valid because I validated it before pruning. However, how do I know that this transaction spends an unspent input? Do I need to ask for the merkle path of the referenced transaction and keep doing that?

I think you are confused here. While operating a full node in prune mode, your node will download every block and perform full validation. Each transaction that gets processed will update the UTXO set that is cached on your node. Therefore, you will know if transactions are spending valid UTXOs or not.


BTC wallet recovery: I have a 12 word backup, what do I do?

Try this,
https://wallet.mycelium.com/
YOu may find more relevant information here as a second option.
https://wiki.trezor.io/Welcome


What's the deal with "legacy" and "segwit" wallets?

Later I read that it's impossible to transfer bitcoin between those two kinds of wallets. Is it true?

This is not true.
However a wallet needs to know about Segwit addresses in order to be able to send to them. Since it is a new address type (well new when it was introduced 3 years ago), software that hasn't implemented it yet won't know what to do with it.

I tried this kind of transfer (legacy -> segwit) using Electrum and it didn't work. Does software matter?

In what way did it not work? Electrum supports and uses segwit, so it should, unless you are using an older version of Electrum. Both the software and version of that software do matter.


There are many more parameters than number of confirmations for input selection.  It mainly depends on the amounts used in the outputs because eventually enough inputs have to be used to cover the costs, which means unconfirmed inputs might be used if that's all what the wallet has.

If you want to control the number of minimum confirmations that an input must have before it's considered available for funding, there are two options:

spendzeroconfchange=0 will tell the wallet never to spend an unconfirmed input (0 disables spending, 1 enables it and is default), and txconfirmtarget=6 which will means that an input must be buried beneath at least 6 blocks.

You can change 6 to be something else.


Bitcoin URLs: how to set a transaction fee?

Great question!!!

Here is a non-authoritative answer based upon prior related experience of many years past. The Bitcoin URI-scheme is very reminiscent of the IETF HTTP and SIP URI protocol grammars.

With the suggested Bitcoin BNF Grammar documented in BIP-21, it is possible that implemented pchar "otherparam" or "reqparam" names to be abused to suggest a transaction fee. The fee is digit, not a pchar. The URI could even be made to suggest specific pool(s) to expedite the processing of the transaction (relates to High level details for bundling transactions for solo mining or pooled GBT mining). I'm guessing the issue is the the meaning of the name-value pair for a transaction fee is left up to the whim of a developer which could lead to downstream turnkey Bitcoin component interoperability issues. So does it would make sense for the BIP-021 to be tweaked to add something like the following to its grammar?

paytxfeeparam = "paytxfee=" *digit [ "." *digit ]

**The wallet application currently establishes the acceptable transaction fee. For now, Bitcoin-Qt "bitcoin.conf" "paytxfee" value is used to statically establish the transaction the client is willing to pay.

I can understand why current pool operators may not care about establishing a paytxfeeparam. However, a roaming customer may want to know what it takes to expedite an adhoc in-person brick and mortar transaction for a product or service.

To support commerce, its not too hard to also envision a need for something like:

paysalestaxparam = "paysalestax=" *digit [ "." *digit ]

BIP-21 needs to be updated with a number of other real world use cases...

From a Cybersecurity perspective, I would be very reluctant to click on a URI from that only God knows is from who that induces a very expensive transaction. I'm glad to BIP-21 talks about always requiring the user's authorization.


Storing HTML websites in the blockchain?

To get large blocks incorporated into the blockchain, you will have to pay transaction fees based on their size. It could be an interesting exercise to compare this with storage costs for the same level of long-term redundancy elsewhere---but then again, what is the level of redundancy? If storage in the blockchain does become common, it is obvious that soon most people will (have to) stop storing the entire blockchain locally, defeating the purpose of having a highly accessible and highly redundant storage (for your website example or maybe for backup).

In you wikileaks example, I think this might pretty much defeat its purpose. Although many people may be interested in many of their leaks, surely only a small fraction of bitcoin users will be that interested that they'd be happy to store it without reimbursement for their wasted storage space. And at a reasonable compensation, the person or organization leaking it must be so rich, you'd wonder if it was cheaper to finance political campaigns that can change the system to allow risk-free whistleblowing at lower expense.

Also note that wikileaks is not in the business of releasing most of their information. I believe what they have distributed in bulk is a very strongly encrypted version of everything, and very selective, carefully edited small bits. The encrypted bulk would not give the benefits you imagine (allowing anyone to browse it)---and luckily also none of the risks, I might add (just imagine any of what the media has actually redacted out of their stories included something actually dangerous, like, say, the key with which some madman could trigger WW III). And it is not needed: As I understand it, plenty of people have downloaded and spread their encrypted bulk data for free and out of their own volition. I suspect if you wanted to get it, you might still find it easy to find online. Just what you might hope from getting out of browsing an encrypted monster-sized file is a bit beyond me; it seems to me the only benefit is knowing to have helped slightly with wikileak's self-insurance policy.


You can see all available command options by running the command bitcoind -?.
Similarly, in the GUI you can check out "HELP" -> "Command Line Options" in the task bar.

This will return a list of all available commands, as well as their default values (when applicable). Note that this just returns all possible command options, not specifics about what you have set. Default values will be used unless you specify otherwise, and I believe the hierarchy for specifying a command option is:

An option passed on command line when starting bitcoind
(takes precedence over)
an option passed in .conf file
(takes precedence over)
an option set in the GUI

(Information pulled from here)


Yeah, check out this answer on tex.

% arara: lualatex

\documentclass{article}
\usepackage{fontspec}
\usepackage{fontawesome}
\def\faBtc{\FA\symbol{"F15A}}
\usepackage{tikz}
\usetikzlibrary

{positioning}
\newcommand{\bitcoin}{%
    \begin{tikzpicture}
\foreach \i in {0,100}{
    \node [circle, fill=orange!90!white!\i, font=\large, inner sep=0.25ex, rotate=-15, text=white]
    (symbol) at (-1.25,1/8+\i/4000) {\faBtc};}
    \end{tikzpicture}}
\usepackage{mathtools}
\usepackage{siunitx}
\DeclareSIUnit{\btc}{\ifmmode\text{\faBtc}\else\faBtc\fi}

\begin{document}
\SI{1000000}{\btc}
\bitcoin
\end{document}


Is there a minimum size of network for a cryptocurrency to be viable?

This question is too broad. It depends on the currency's system. And the figures are rather arbitrary.

Let's focus on bitcoin's proof of work system. Processing power (of miners) is required here to confirm transactions. Protocol adjusts processing power needed to confirm transactions depending on the current processing power.

If total processing power is low it is easy for attacker to enter the network with large processing power (comparable to total current processing power) and execute attack.

So it is important to have huge processing power in the network and that it is as much as possible distributed among the miners.

What is considered huge is arbitrary. What is considered sufficiently distributed is also arbitrary. Currently in bitcoin you have large mining pools that you can considered each a single miner. Don't know how many of these together at the moment have processing power comparable to all other miners.

If 10 mining pools have over 50% of network processing power they can (in some scenarios) collaborate and execute attacks.


Can you track your payment if you do a transaction from person to person for a house rental if the seller doesn't follow through with their end of the deal and doesn't send the keys can you get your money back?

You can view your transaction's status on a block explorer or your own node, if yu have one. You cannot get the money back unless the other party explicitly sends it back to you in a new transaction. Bitcoin transactions are irreversible once confirmed.

  Or in other words is there a record of your transaction so you can claim a dispute or track down the person who didn't follow through?

Bitcoin is a decentralized system. There is no one to file a dispute with.

  What safety do i have in this aspect for example i am applying for rental house but i found out they're in the states and I'm in Canada so they have to send me they keys but they want the payment first through btc wallet so if i do this and send the bitcoins and he doesn't send me the keys and i find out it was a scam is there a way for me to recover my payment?

Usually, for such transactions, you would utilize an escrow service that only releases the BTC to the seller after you have received what you paid for. You should ask the seller to use a reputable BTC escrow (there are a few on Bitcointalk). If the seller refuses, you should proceed with caution, if at all, as many people are scammed by such offers.


The best way for you to purchase the funds are to go to http://www.buymastercoin.com/ and make  a purchase as described on the site.

Or just go to the google spreadsheet that is used as a sort of an exchange where you can purchase from the MSC holders themselves: https://docs.google.com/spreadsheet/ccc?key=0ApGPLGUd5ZCzdHFxbnhHQjBDSDVKamY5UHlWdkNMNWc&usp=sharing#gid=0

No need for a special Wallet but it is definitely recommendable to make a new address for the Mastercoins


When computing the hash, do you need anything after the number of difficulty bits?

The first 00000000 is for the nonce. The nonce is changed in order to get a different block header without reselecting transactions. It is what is used primarily for finding a valid block hash.

The long string of bytes beginning with 0000008 is SHA-256 padding. It is not actually part of the block header and whatever is doing the SHA-256 hashing should figure out and append this padding for you. It is part of the pre-processing step for SHA-256.


By setting the -prune option.

  -prune=
         Reduce storage requirements by enabling pruning (deleting) of old
         blocks. This allows the pruneblockchain RPC to be called to
         delete specific blocks, and enables automatic pruning of old
         blocks if a target size in MiB is provided. This mode is
         incompatible with -txindex and -rescan. Warning: Reverting this
         setting requires re-downloading the entire blockchain. (default:
         0 = disable pruning blocks, 1 = allow manual pruning via RPC,
  550 = automatically prune block files to stay under the
         specified target size in MiB)

The feature was originally introduced in Bitcoin Core 0.11 (see release notes).

As of version 0.12 pruning can be used while running a wallet. But note the -txindex and -rescan caveats.

Also note that the specified MiB will only include the block files and some undo space. Besides that you will also need some disk space for the chain state and block index databases.


How do I configure a port in my .conf file?

Windows 10

Run netstat -ab >file.txt then notepad file.txt and search on 5040. I suspect you will find CDPSvc immediately underneath - on my machine this "Connected Devices Platform Service" is already using your port.

If that's so, search on 5041, then 5042 and continue up until search can't find it. That port is free: change your rpcport to match it.


Proof of private keys ownership for multiple addresses

Why would you prove ownership of inputs/outputs in two-party coinjoin? This data upon publishing would make the coinjoin efforts obsolete and would totally cancel all anonymity set in this specific transaction.
For input you could use some specific wallet setup where inputs would be in separate xpub derivation path, and outputs in separate.
Even with point 2. you'd have to post the outputs as the list of addresses if you don't want to leak pubkeys?

This looks to me like an XY problem and your requirements are contradicting themselves. Could you explain what you're trying to achieve?


How much space does the blockchain take up per day and per hour when running bitcoinQT on my computer?

The blockchain size growth is kind of approximately linear at this time (although I wouldn't expect it to continue linearly). See the nice graph at https://blockchain.info/charts/blocks-size and particularly check the "All Time" scale option.

Over the past year, the blockchain size has grown by approximately 10 GB. On average, that would be around 27 MB per day, or 1.1 MB per hour.


Cryptocurrency Arbitrage - What do I need to know?

Arbitrage - What it is and how it works

Arbitrage refers to the process of instantly trading one or more pairs of currencies or odds for a nigh risk-free profit.

Usually, this involves two exchanges (this is then called a two-legged arbitrage); although more are, of course, possible.

There are several steps when executing an arbitrage:

Find a suitable opportunity
Execute trades
Rebalance accounts

Step 1: Find a suitable opportunity

This step is relatively easy. Simply check the order books of as many exchanges as you like, compare bids vs asks, and check if you can find a negative spread.

A small discourse into what a spread is

I will assume you're familiar with bids, asks and what an order book is - if not, you should definitely look up those first.
As for the negative spread, I'll elaborate a bit more on that. The spread is what is used to refer to the difference between bids and asks - lowest ask - highest bid = spread. This should be (and typically is) a positive value, since the best bid at an exchange must be lower than the lowest ask of an exchange - otherwise the matching engine of the exchange would settle these orders automatically.

In a perfect world, all markets and all market participants would have the same information, hence all top bids and all top asks of all exchanges would be the exact same, after fees were applied.

If you've seen the recent US elections, however, you're probably aware that the world isn't perfect, though. Hence, not all participants of a market know the same thing as the others, resulting in bids at exchanges which are higher than the asks at other exchanges - and this is what is called a negative spread.

Step 2: Execute trades

Let's assume you've found an amazing opportunity at exchange A and exchange B - a negative spread of 100$!

Exchange A: Ask 1BTC@450$
Exchange B: Bid 1BTC@550$

Luckily, you have proper funding at both to match these instantly - but how do you go about doing that?
Easy! Just place an order on the opposite side at each exchange with the quote's prices!

Exchange A: Place Bid of 1BTC@450$
Exchange B: Place Ask of 1BTC@550$

Since your placed order match an order on the opposite side of the book, the trading engine matches them and the trade is settled, leaving you with a theoretical profit of a smooth 100$! Why theoretically, you ask? I'll get to that point further below.

Step 3: Rebalance Accounts

Unfortunately, you were only able to trade once today, but hey! Tomorrow's another day - but in order to be able to properly trade, you need to even out your balances. Right now, your accounts look like this:

Exchange A: 2 BTC | 50$
Exchange B: 0 BTC | 1050$

Hence, you go about and send 1 BTC from Exchange A to Exchange B, and 550$ dollars to Exchange A from Exchange B. No magic here - all accounts are re-balanced and you're ready to make a fortune again, tomorrow.

Exchange A: 1 BTC | 550$
Exchange B: 1 BTC | 550$

Arbitrage - Why everyone's not doing it

This all sounded wonderful? That's exactly what I thought when I first set out with my own arbitrage bot. However, there a some technical aspects that can really turn a sunny day into a poopy rain on your parade.

Caveats and risks

1. It needs to be as close to real-time as possible

This is possibly one of the hardest things to get right, and also the most underestimated aspect of arbitrage in crypto currency. The markets, compared to ForEx trading, are ridiculously slow - at busy exchanges, there may be a couple of dozen trades executed. Which gives the illusion, that polling data for bots via the most common API type, RESTful, is enough to trade risk-free.
This is a misconception. Maybe for today this may appear to be enough - but what if markets picked up the pace? just 1 trade (or simply a placed order) within one second can change your opportunity from profit to loss.

2. Always trade limits, never market orders

Under the aspect of being the fastest, it might seem like a good idea to use market orders in order to be settled asap - you'd be terribly wrong. As discussed above, your data could be as old as 1 second (with above mentioned one order messing up your opportunity) - perhaps someone cleared the entire top level and all you're left with is a bid for twice the price you intended. Yikes.

2. REST API call rates make your life hard

Many exchanges employ a API call rate limit - that is, you're allowed to query data at the exchange X times every Y seconds. The differences are wide and nearly every exchange does its own little thing when it comes to limits.
The problem with them is, they severely limit your actions. If you don't constantly keep an eye on how often you send a request, you might run into the limit when it seriously counts - for example when you have to cancel an order, because you couldn't place its counter part at another exchange.
Unfortunately, websocket APIs are still rare and their brother on steroids, FIX sockets, even rarer - leaving you stuck with the turtle of programmable interfaces.

3. Integration with APIs can be a nightmare

There is no unified, standard definition for what an exchange API can do, or what data it returns. Which technically wouldn't be a problem, if they were documented properly. Incidentally, the exchanges with seemingly many opportunities also have the worst documentation (take btc-e.com's Documentation for example - heresy!).
Of course, also the opposite is true - GDAX, Kraken, Bitfinex all have excellent documentation. But nonetheless you have to dig through them to understand how they work, what their rates are, how they handle data types, authentication and so forth. That is, if they even mention anything about that.

4. Fees will minimize, if not eliminate your profits

In my above step-by-step guide, I purposely omitted fees of all kind. But of course, they're essential to successfully arbitraging. The most commonly known fees, are trade commission fees - these range anywhere from 0.1% to 0.6% and need to be considered in Step 1: Find a suitable Opportunity. On top come fees for deposits and withdrawals during Step 3: Rebalancing Accounts. Depending on your preferred pair, these may range from feasible (transferring crypto currencies usually is cheap enough) to quite steep.
For example, a deposit / withdrawal at Bitfinex entails the following fees:

Bank wire withdrawal & Deposit: 0.1% of amount deposited/withdrawn, 20$ minimum

And this does not include processing fees of your house bank - for me, for example, that's an additional 10€ for deposits, plus a 1% conversion fee.
If you do the math you'll quickly realize that you don't even have to bother starting to trade at Bitfinex, unless you have a really big stack to trade with.

But this does not just apply to BTC-Fiat pairs. Alt-coins suffer a similar fate. In order to make arbitraging worthwhile, you will have to have enough funds at as many exchanges to make trades AND re-balancing worthwhile. And this quickly gets to a point where you realize your last month's savings aren't equipped to get the job done.

  To give you a further example on how fees affect your profits, let's take a look back at the example from step 2, this time factoring in all fees. I'll walk you through it. For the argument's sake, we'll pretend to be a european trading BTCUSD at Bitfinex (Exchange A) and Kraken (Exchange B).

  Bitfinex: Ask 1BTC@450$
  Kraken: Bid 1BTC@550$
  These prices are raw- they do not include trade commission fees, not transaction fees. Let's add those.

  We'll define a taker fee of 0.25% at both exchange - the taker fee applies whenever you remove liquidity from the order book.
  Next, let's add deposit & withdrawal fees to the mix. At Bitfinex, we pay a minimum of 20$ for each fiat withdrawal & deposit, or 0.1% of the moved amount (if its more than 500$). At Kraken, we pay 0.09€ per fiat withdrawal, deposits are free.
  In addition, btc withdrawals cost 0.0005 BTC at kraken, while Bitfinex charges no fees for this. Deposits cost nothing at both exchanges.
  Furthermore, we can't transfer fiat directly from exchange to exchange - an additional 10€ fee per sent out transaction needs to be facotred in, as well as 1% conversion fee whenever we receive or send fiat from our bank account (2 times total).

  Let's list these fees to try and maintain an overview

  Profit from arbitrage (bid - fee - ask + fee )
  Withdrawal Fee Bitfinex  (20$)
  Deposit Fee Kraken (0.0$)
  Miner Fee for withdrawal at Kraken (0.0005BTC)
  Transaction Cost of our house bank (10€) (Bank to Bitfinex)
  Conversion Fee of our house Bank (1% of transfer amount x 2)

  Let's put some numbers to these:

  (550 - 550*0.0025) - (450 + 450  * 0.0025) = 97.5$
  Move ~497$ to House bank = 20$
  0.0$
  0.0005BTC * 500$ = 0.25$ # Assuming this is the end of day price of the  coin
  10€ * 1.05 = 10.05$
  (497 * 0.02) = 9.94$

  Which brings us to net profit of: 57.26$
  This translates to 42.74% reduction of your originally seen profit.

  This is neither a worst, nor a best case scenario - it's merely designed to show you how many hidden fees are involved in an arbitrage. Also, keep in mind that a 22% arbitrage opportunity is practically non-existant.

  As a matter of fact, had the spread been anything less than 40$, the fixed fees of our house bank and Bitfinex alone would have made our supposed arbirtrage opportunity a loss.

5. Volatility of coins is your enemy

  "No matter where the market goes, arbitrage makes a profit anyway!"

This is true - if your currencies don't tend to drop or rise by 50% within 24 hours. Ideally, both currencies you trade in should be relatively stable, while still showing a certain volatility - no volatility would mean the chart is a flat line, resulting in no opportunities for you.

The problem with pure crypto currency arbitrage (LTCBTC), however, is that Alt-coins can go completely fubar - as opposed to a fiat-based crypto arbitrage (i.e. BTCUSD).
A personal anecdote:

  When ZEC launched, I was instantly fascinated at the terrible market efficiency and arbitrage opportunities of almost 5% regularly. Hence, I bought in at 1ZEC@1.2BTC, thinking this is probably where market will stay at (at least it's not as bad as the guy who bought a ZEC for 3k BTC). I started arbitraging and immediately increased the amount of ZEC I was holding - completely oblivious to the fact that since I started trading, the price had fallen to 1ZEC@0.1BTC. My ZEC was worth 90% less, and I lost almost half a bitcoin worth of money.

Some volatility is great for arbitrage - too much volatility isn't.

6. Exchanges aren't as technically robust as they ought to be

Most of the time, you will find that smaller exchanges offer opportunities more often than big exchanges. This is in part due to the previously mentioned slow movement of information, but also their (often significantly lower) trading volume. Initially, this may appear like a steal - but there's usually a reason that particular exchange only has the low volume it currently does.

In a time where any one in the world can open up an exchange running on his Raspberry Pi and Ethereum, trading on the more alternative exchanges can be a serious risk to your investment.

From things like DDOS attacks and overloaded matching engines not matching your orders, to more serious issues like stuck withdrawals due to too low miner fees, or even theft - and the latter is a very real issue not exclusively affecting small exchanges, as the Bitfinex Heist has shown summer 2016; the list of potential technical failures is long and you should be aware of these at all times.

Conclusion

I'm aware this answer is overtly negative - this was intentional. Arbitrage, as well as crypto currency in general, is not the quick buck everyone on forums and dubious sites advertising trading bots make you believe.
While its inner mechanisms and workings are still quite cryptic* to even the most professional traders (sorry for the pun), even the fabled cryptocurrencies adhere to some basic principles, afterall. The 'quick way to wealth' usually will just end up quickly making you wealthless.

(*) Another great myth is that the chinese dictate the BTCUSD market. There is no empirical proven correlation between chinese and american markets. The only defacto correlation that has been found was that of google searches for bitcoin to btc trading volume - but whether this was positive or negative was inclonclusive.

Please feel free to add, comment or make improvement suggestions!


Best Python API for sending Bitcoins from a Multi-Sig wallet

Maybe pyCoin can be useful for your purpose?
https://github.com/richardkiss/pycoin/blob/master/COMMAND-LINE-TOOLS.md


What's the longest chain of orphan blocks? (How many confirmations have been necessary?)

The longest orphaned fork was created due the "value overflow" bug occurrence, ranging from block 74638 to 74691 (so 53 blocks). Such a situation is unlikely to ever repeat though.

Other than that, as far as I remember 4 blocks were overwritten by some strange behaving miner (related question), but I might be mistaken.

In general, 6 confirmations is enough in most cases to prevent any double-spend attempts, and 120 confirmations is enough to give the developers time to release a fix for some major bug that might occur before the coin creation transactions are mixed in with everything else, creating a big mess.


I lost my Bitcoin wallet passhrase. Are my Bitcoins lost?

If you have encrypted your Bitcoin.org wallet with a passphrase, then only having that passphrase will allow that to be decrypted.

If you have a backup of your wallet prior to performing the encryption step, then any coins from that wallet that still have not been spent can be recovered.

Otherwise, without that passphase to open the wallet you cant get to the private keys inside the wallet, and thus cannot spend those funds.

There is no difference between "lost coins" and "unspent" coins, so no there are nothing more than anecdotal evidence as to how many coins have been lost.

There are ways to try to recover your wallet based on hints about what you remember about your passphrase.


Will Bitcoin Cash (BCC) be mined like BTC?

Will the new bitcoin-cash be available for mining and if yes, is it
  mined on new fork that will be submitted or on the previous code?

Yes, it will be available for mining, and you mine it the same way you mine BTC, all you need to do is direct your hash power to the pool which will be mining BCC after the split.

ViaBTC provide such a pool for BCC mining and it is available now, https://pool.viabtc.com/pool/bcc/home/


It looks like they have been archived over at archive.org.


The bytes you would put in the block header would be, in order: 0x00 0x00 0x00 0x20. That's how the number 221 (= 0x20000000) is stored in 32-bit little endian encoding.
Note that this is actually a large number; that range is used for BIP9-compatible versions. Older blocks that use versions 1 through 4 predate BIP9.


How can non-Coinbase customers pay to Coinbase from Android?

The coinbase payment page has a "pay to address" option that will generate a unique address associated with your order and display a QR code. User can simply send payment to that address.


it still needs a 3rd party (miners) to approve/authorize/record/track/store transactions

Role of miners vs other participants
In the beginning miners were not a third-party, every wallet owner was also a miner, all peers performed the same roles.
Nowadays mining has become a separate activity but miners do not really have any special control over the bitcoin network. They have a specialized role but I believe their influence over consensus rules carries the same weight as ordinary wallet nodes. Its just that a mining business deploys a lot more nodes than the average wallet owner does. In any peer-to-peer system, even a completely homogenous one, one person or organisation could deploy a large number of nodes.
approve/authorize/record/track/store transactions
approval
All nodes approve transactions, if all ordinary wallets disapprove of blocks from a miner then that miner loses money.
authorisation
There is no authorisation in the Bitcoin network protocols or consensus rules so far as I know.
The only action similar to authorisation is the P2P process of proving ownership of private keys in order to prove the right to spend the outputs of a transaction. Every wallet does this.
Recording transactions
Miners are responsible for recording transactions in the blockchain. So they do have a special role here. Bitcoin relies on no single organisation having more than 50% of the total available hashing power.
Tracking transactions
All full-nodes track transactions (i.e. keep local records of transactions in blockchain blocks as well as maintain an in-memory pool of unconfirmed transactions). Miners have no special role here.
Storing transactions
All full-nodes store a complete list of transactions from which blocks of fully-spent transactions are optionally pruned. Miners have no special role here.

Why is it not a complete p2p (like gold, fiat cash) electronic cash?

Gold is not P2P in the modern world. Generally people who buy and sell gold directly do so in the form of coins or ingots - the production of coins and ingots is performed by a limited number of businesses not by the buyers and sellers. Often it is governments that mint gold coins. Often governments regulate the gold market. Gold assayers are often relied on by buyers.
Fiat cash is not P2P. Banknotes and coins are typically created by governments, not by buyers and sellers. The amount of fiat cash in circulation is typically managed by governments. Inflation rates are set at the whim of politicians.


POS coins are not mined in the traditional sense. See, mining is a way to make people expand some energy so no one person can defeat the network by generating fake blocks and appending them to change transaction history. Miners are usually rewarded coins.

See even in POW, the coins aren't mined, they are just generated and awarded to the person who solved the computation. The get the reward because they had to expend some energy to maintain the network
So you see, even in POW, the coins aren't really mined are they?

For POS, you can do an ICO and stake some coins to active wallets. Those people can then begin to use the system. You literally generate coins and issue them out and force people into this staking system in order to make any transaction on the network. Of course, we still haven't solved the distribution issue facing human kinds economic system.

Satoshi did give us a start however.


Probably the reason why it is not added is because it wasn't considered "one of the main ones" whatever that means. You can write ILS yourself though: you can use whatever three letter code you like.

Alice trusts Bob for 10 XYZ.

Alice and Bob know what XYZ represent. If you and your friends (ripple neighbors) use ILS, you know it represents New Israeli Shekels, the system only needs to know that it is the same currency so that it can apply a 1:1 exchange rate.
For more information on this, read this issue and this forum post:

https://github.com/rippleFoundation/ripple-client/issues/77

https://ripple.com/forum/viewtopic.php?f=1&t=7

EDIT: To trade ILS, manually edit the text within the selector for the currency pair. For example, substitute "XRP/BTC" for "BTC/ILS" and that's it. Of course you need to specify the issuer for ILS and BTC as always.

EDIT2: Now currencies will be ordered upon usage. The more you use a currency, the higher it will appear on the selector's list.
https://github.com/rippleFoundation/ripple-client/commit/1a44e94844d6948d103e31c6121dcb71d5b65ef1


X11 | multiplier & maxDiff number to multiple the shares by in order to display hashrate


How to redeem Non-standard script Tx (testnet instance)

The first redeeming transaction has a scriptSig in the form:

<value to be double hashed> 0 <signature> <public key>

That 7e is a red herring - it's the size of the scriptSig. Similarly, the 10 is the size of the data to be hashed.

The second transaction appears to be attempting to spend a standard output. It appears to be trying to spend this using a key that doesn't hash to the right value.

You can see this by pasting the following script into Bitcoin Script IDE:

042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG


It is always advised to backup your wallet.dat before doing anything with the client, and also to keep a general backup just in case.

As the file saving protocol in Bitcoin client rarely changes, one can possibly run a couple different versions on the same .dat files without an issue. However, running an older version after an update is not advised, as unexpected behaviour can happen every now and then.

So you should backup your wallet.dat, uninstall the old version, install the new version, check if everything is working okay, and then delete the temporary .dat backup.