text:
How do I reduce the size of the block chain data on my machine?
The block chain file is getting rather large, ~500MB.  Is there a way to trim it or clean up, or maybe configure it to be limited in the future?  I am using the stock Bitcoin client on Ubuntu.

For portable devices there are variants of the Bitcoin client often dubbed "selfish clients" in that they do not download any portion of the block chain other than what pertains to their own specific addresses and transactions. To my knowledge, none of these variants has been fully developed into a desktop client, but it is likely that such projects are underway. Unless your system is literally lacking the hardware to accommodate these files, however, it is recommended that you use a non-selfish client version. The lightweight versions are called "selfish" for a reason - by only holding block chain data which pertains to your own transactions, you cannot pass anything but that data to other nodes and as such your client is of minimal (if any) use to the network.

Also, at the time of this writing, hard disk space is about $50 per TB which means the 500 MB block chain is costing you about 2.5 cents to store - "selfish client" may not be an overly nasty moniker after all.

For platter based disk space yes, but my main machine is SSD which is about $2 per GB compared to $0.6 per GB and at 60 GB you have to  keep on eye on it.  I also may wish to look into Point-of-sale devices that may be using simple 12GB or 16GB SSD's and it may be a consideration.

@DavidPerry What are the security risks in not having the entire Block Chain?

@Pacerier to my knowledge there aren't any meaningful security risks, you simply have an incomplete dataset. As long as the dataset contains all the blocks which are pertinent to the addresses you're interested in (i.e. the ones you own) then there shouldn't be any issues.

@browep Most of the point-of-sale devices you're referencing already run credit card transactions through a server in a back room or via an attached embedded device anyway. Bitcoin has a built-in RPC mechanism for just such purposes, not to mention services like bitpay. It might not help save your expensive SSD, but you're an edge case - in almost every case either a) hard disk space is cheap or b) RPC/bitpay/ewallet is a better (and not unreasonable) option.

If you want to use the standard client, currently there is no way to prune the blockchain data. However, you can try using a lightweight client (like MultiBit or Electrum), which offers similar security to the standard client (wallet.dat is stored on your computer), or an eWallet (like StrongCoin, or even using MtGox if you don't need too much functionality), but then you have to trust that service.
The first two would reduce the disk space on your machine, but you'd still need to synchronize with the network; the second two would make you store nothing on computer and you would not need to synchronize.
There is work being done on a "Stratum client", which might offer the speed and minimal disk requirements of an eWallet with security of a lightweight client.
You can read more about various levels of security provided by different types of clients here.

The short answer is: No.
The Bitcoin client requires the entire block chain in order to validate transactions, and the block chain is currently around 500MB. It will continue to get larger and larger over time.

NOTE: Do not use this solution.  It is no longer relevant for current clients. See other answers for suggestions on how to use incomplete blockchain representations.
The current version of the client doesn't offer much in the way of optimizing space, and does some caching that may cause bloat, but here are some ideas for manual ways that could help.

Copy the wallet.dat file out of the data directory, then remove the data directory.  Restart the client have it build the data directory again and download the block chain. Stop the client replace the wallet.dat file with your backup. Restart the client with the -rescan option.
Backup your entire data directory and remove it. Start the client again creating a new data directory, and block chain download. Copy an address from the client. Close the client, backup the new data directory as a different backup.  Restore the old directory.  Start the client and transfer all of your coins to the new address.  You can then restore the number 2 backup of the data directory, and discard the old directory. In this scenario you do not need to restart the client with the -rescan option.

However, be very careful with these steps, and keep all the backups until you are sure you are successful.  And remember that if you are expecting payments on the old wallet.dat file then you shouldn't use option two unless you can easily update the payment address to your new wallet.

Will that really help much in the way of space? The block chain is the block chain and it /is/ getting pretty big.

I will leave this here for historical value, and to avoid a future duplicate of this answer, but it is no longer a relevant solution.  There may have been some inefficiencies  in an earlier client versions, but there is no evidence of that now.  As @lemonginger and others point out the block chain is what it is, any solution will involve not using the the full block chain.

You can use the -prune command when you execute the core.  This will strip down the blocks your client maintains to only the essential.  For me it has pared down the size of the btc Blocks folder by a third.
Add -prune to the end of your command line when you go to run the bitcoincore  executable

All command-line options (except for -conf) may be specified in a configuration file, and all configuration file options may also be specified on the command line. Command-line options override values set in the configuration file.

You can also add -prune to end (outside the quotes) of the Target text in the properties of the bitcoincore GUI shortcut.

I don't believe you can, actually, which is one of Bitcoin's wee little problems, along with a too-long-gap between difficulty computations.
In order for Bitcoin to take over from the dollar, you'd have to have the entire economy of the USA on everyone's computer. That can't happen.
In order to fix that, we will have to modify the block chain system and that is DAMN DANGEROUS, because in spite of all the scandals around Bitcoin, Bitcoin itself is immutable, nothing has ever been found wrong with it's actual data structure itself.

In fact there have been vulnerabilities in core Bitcoin... see for example https://en.bitcoin.it/wiki/Incidents


text:
Can I restore a wallet using any valid 24 words?
Can I create a wallet and restore it on something like a Ledger S using any 24 words that I choose from the list of accepted words?
Is there any disadvantage to creating a wallet this way instead of having say Ledger generate 24 words for me?

The short answer is NO because of a checksum. You are playing with fire if you are arbitrarily using the list of words from https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md#wordlists.
However, you can synthesize a list of from a from triplets of 3, 6, 9, 12, 15, 18, 21, and 24 words using 32, 64, 96, 128, 160, 192, 224, 256 binary seeds. See the three working examples below that use Bitcoin-Explorer (bx) command line interface.
24 Word Example:
% echo -n "This is a crappy brainwallet!" | bx base16-encode | bx sha256 | bx mnemonic-new
swear favorite title elegant eye trim situate velvet own atom change same net winner seven drum thunder subway convince arrive bid notice during vacant
18 Word Example:
% echo -n "This is a crappy brainwallet!" | bx base16-encode | bx sha256 | cut -c 1-48 | bx mnemonic-new
swear favorite title elegant eye trim situate velvet own atom change same net winner seven drum thunder surround
12 Word Example:
% echo -n "This is a crappy brainwallet!" | bx base16-encode | bx sha256 | cut -c 1-32 | bx mnemonic-new
swear favorite title elegant eye trim situate velvet own atom change sail
From the working examples above the checksum causes the last word of the triplet set of words to vary.

If you choose the words yourself, you're more likely to be biased towards some word selections based on position in the list, words you like and dislike, etc. Ledger is designed to pick the words as securely as possible. Also, some words are used as checksum I believe, so if you just picked them randomly the checksum would be invalid and you'd probably get a warning. But yes, it would still probably work.

There is indeed a checksum as specified by BIP 39.  I don't know how Ledger works, but I would expect that it would reject a phrase with a checksum mismatch, not merely give a warning.  If that's the case then it would probably NOT work, with probability 255/256.

You can generate your own master seed and use the resulting mnemonic in a restore function on any BIP39 compatible wallet.  On the BIP39 generator, you can opt to enter your own entropy number (in hexadecimal, decimal, binary, etc.).
This approach is probably more reliable than directly choosing the words yourself.
"Is there any disadvantage to creating a wallet this way instead of having say Ledger generate 24 words for me?"
If you use a strong enough password in addition to the seed words, then no.  The password changes the master seed, so even if the seed words are released publicly, nobody can access your funds or generate your private keys unless they know your password.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
local bitcoin nodes in a same vlan cannot sync
I have two local bitcoin nodes, node1(192.168.105) and node2(192.168.1.101). Firstly, I start node1 to connect the bitcoin network to download some blocks. Then I delete the static dns seeds in file chainparam.cpp for both two nodes. So they both cannot connect to the bitcoin network.
I started node1 with “./src/bitcoind -datadir=/bitcoin_block -listen=1" and node2 with "./src/qt/bitcoin-qt -datadir=/bitcoin_block". And in order to connecting node1, using command "addnode 192.168.1.105:8333" on node2 through the debug window/console.
The status in node2 shows,

We can see that node2 has connected to node1, but cannot sync blocks from node1.
I checked the node2's debug.log and found "Ignoring getheaders from peer=0 because node is in initial block download". Then I changed the nMinimumChainWork value to a more smaller one and provide -maxtipage when starting node2 to make the following check failed(suggestions from Altcoin connecting nodes). But it still won't sych.
"chainActive.Tip()->GetBlockTime() < (GetTime() - nMaxTipAge)".
Is there anyone can give some advices here? It really stuck me here. Appreciate your help.

I was using bitcoin-0.14 and I forgot to change the chain limit parameter(nMinimumChainWork). It works fine after I lower down the limitation.

Then I delete the static dns seeds in file chainparam.cpp for both two nodes. So they both cannot connect to the bitcoin network.

They can still connect to the Bitcoin network without the DNS seeds. The DNS seeds are not the only way to connect to the network; there are numerous fallbacks, with DNS seeds themselves being a fallback too.
-datablock= is not a valid command line option. Did you mean to use -datadir?
Check in the debug window of both of your nodes; does node1 have a number of blocks that you expect it to have? Does node2 already have blocks that it downloaded very quickly and you didn't realize it?
Instead of using the addnode RPC, try using the -addnode or -connect startup options to connect your nodes.

There's no connections after i deleted the DNS seeds and no data being downloaded.

Yes, I mean -datadir, sorry for the misunderstanding.

I checked there's no blocks in node1 except genesis block. And node2 did't get any blocks after I deleted its seeds in chainparam.cpp.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How can I tell Bitcoin to only spend confirmed inputs and self created outputs
I want to make sure that the transactions I create with the original client are always using confirmed inputs and self created outputs.
Bitcoin used one of the transactions that I describe here in this question: Stuck duplicate transaction in BitcoinQT
as an input. So the new transaction is not being confirmed either.
I want to make sure that my transactions are always using confirmed transactions. Is this possible?

You can't use self-created outputs until they have sufficient confirmations. Otherwise, your transactions can fail to confirm due to signature malleability.

Hey David, thank you. Do you mean I shouldn't or I can't? Because like I said in the question, Bitcoin did use a self created transaction that has 0 confirmations as an input. Mind you that the both transactions are still unconfirmed. And I think they never will be. Because the input transaction is a duplicate of another transaction that did get confirmed. What I mean by duplicate is exactly the same inputs and outputs but different TXid.

Right, that's why you don't want to use even your own outputs until they have sufficient confirmations. You don't know what the transaction ID will be.


text:
Explainations about chaining of transactions
I'm reading through Satoshi's paper, and in Section 2. Transactions, he starts by saying:
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
Then there is a good diagram that shows this in the paper

So, effectively if BTC0 is the previous transaction, the new transaction is:

Kp(Owner1)
hash := H(BTC0,Kp(Owner1))
S(hash,Ks(Owner0))

where

Kp(Owner1) is the public key fo the recipient (Owner1)

hash := H(BTC0,Kp(Owner1)) is the Hash of the prev transaction together with the pub key of the recipient

and

S(hash,Ks(Owner0)) is the previously computed hash, signed with the private key sender (Owner0)

I have a  couple of questions:
Here I've indicated the 'previous transaction' is BTC0- is this the previous transaction for that Coin, or the previous transaction on the chain? Danielle Drainville suggests it is "the previous transaction in which this coin was used is hashed together with the recipient's public key" in her paper (An Analysis of the Bitcoin Electronic Cash System)
If so, there must be some kind of search for the previous transaction first?
And, if I understand correctly, there are no 'Coins' in your wallet...the wallet stores the Block Chain, that is, the Transactions log, and your pub/pri key(s). When you're wallet displays to you, the number of bitcoins 'in' it, its actually the result of a search of the Block Chain?

What isn't your rep enough for? Someone can inline pictures for you, provided you give the url somewhere.

I finally managed to merge my accounts!

I don't fully understand your question, first a reaction on your assumption.
It is indeed so that your wallet does not hold actual coins. However, consider the distinction between the terms wallet and client. This is not an official distinction, but it is useful to understand the two different principles.
A Bitcoin client, stores the complete block chain. When you request information about an address or a transaction, it can inspect the block chain and retrieve the requested information. So indeed balances are retrieves by a query to the block chain. Most clients keep an index of all transaction of your addresses so that these queries can be achieved very efficiently.
A wallet often refers to the set of private keys of your own addresses. For the default Bitcoin client, this is the wallet.dat file. It contains a list of the addresses you own and the corresponding private keys you need to make transactions with your addresses.
However the term wallet is also often used for a Bitcoin client, f.e. on the Bitcoin homepage. A caveat here is that some of those wallet indeed do not store the complete block chain but have other techniques to implicitly query the block chain in another way. This sort of clients are called lightweight clients.

Now, what a transaction is, in principle, is just a handing over the control over a certain value in the block chain to another address.
For each address there are zero or more transactions that have the address as output. When you did not send them over to someone else, the are called unspent bitcoins or unspent transaction outputs. The sum of those make up the balance of the address.
When you want to send these coins, or a part of them (note that there is no notion of a coin, but just some value of currency that you send which can be any decimal number up to satoshi precision), you make a transaction in which you claim some of the unspent outputs for your address (as inputs for your transaction) and distribute the value they have over other addresses (which are the outputs for your transaction). So the unspent outputs for an address can be used as inputs for a transaction.
When you sign the transaction and it gets verified in a block, the unspent outputs are now spent and new unspent outputs have been assigned to the addresses you specified in the transaction outputs for the transaction.

Steven- Thank you. You're observation about the distinction between a wallet and client is interesting. When I spoke of a wallet, I was indeed referring to the client. By your definition, the client HAS A wallet; the collection of keys. In my mind, the term wallet is a more user friendly name for the client, as it relates it to the real world equivalent. My question that you didn't understand, as to do with the 'previous transaction' thats hashed -is it the previous transaction in the chain or the previous transaction of that coin? Understanding he inputs/outputs will help I suspect.

Most peope call clients wallets, that's why the distinction is not really officially true, but it's useful to understand the different principles. I'll try to explain your question in the answer

As I have read the source on a few client now (bitcoin, bitcoinj, and libbitcoin) I'm come to learn that the wallet (wallet.dat, xxx.wallet or whatever the client names it) is more than a collection of keys and addresses.
Each client implements the wallet differently, but this comment from bitcoinj sums up its purpose:
"A Wallet stores keys and a record of transactions that send and receive value from those keys. Using these,
it is able to create new transactions that spend the recorded transactions, and this is the fundamental operation of the Bitcoin protocol."


text:
Can a blockchain offer transparency to a humanitarian aid supply chain?
I am located in a middle eastern country which is in desperate need of humanitarian aid.
I have contacts in western countries who are willing to call upon their independent donor network to provide significant amounts of aid in the form of physical assets (not financial). However there is concern over the transparency of the supply chain on the receiving end, as it is typically the case that physical assets tend to disappear in the region, whether they pass through official channels or not.
Therefore, I am interested to know if a blockchain could be used to provide transparency to this humanitarian aid supply chain.
This would greatly increase the confidence of donors and thereby lead to greater amounts of aid being delivered where it is needed.
I have read that blockchain can be used for physical assets and can increase the transparency of a supply chain from a consumer perspective of provedance, but this is the opposite way around, where it is the supplier wanting to have transparency in regards to the beneficiaries of the physical assets.
Furthermore, if this is achievable, I would also be interested to learn how to establish such a blockchain ie what resources or technical knowledge is required or where can these be obtained.
Thank you in advance for any input.
C.

There are already related projects ongoing: "A branch of the UN just launched its first large-scale Ethereum test"

The article about the UN related to funds being distributed, whereas I'm interested to understand if/how the distribution of physical assets can be recorded on a blockchain.

It would largely function by pictures I would imagine. Let's say, for example, each crate of goods had a QR code, EDIT: with the private key known only to the supplier.
So the supplier gets these QR codes(public keys) , slaps them on the crates and sends the crates on thier way. The receiving end then must provide not only a video of those crates being opened in a food distribution center, but the video must include the QR codes in the footage. Then the supplier will know thier goods have not been hijacked, particularly if the video includes the goods being handed out on camera.
Those videos can then be published along with the QR codes for external verification on a blockchain.

The volume would be too great to video and confirm each recipient receiving the goods.  Also if there was a QR code for each crate that could be verified by inspection, would there still be any need for a blockchain?

There is no reason the system you describe could not be engineered as a variation on how Bitcoin operates.
If you want the operation of the blockchain you create to be decentralised then you need three independent miners only (but more is fine and less is fine also if you do not care if it is decentralised but not very redundant) and block creation does not need to be difficult or expensive because you are not trying to provide proof-of-work and with limited miners even the existing algorithm would make it very easy. Block time does not have to be ten minutes on average either as it is with Bitcoin, it just needs to be as responsive as necessary - one block per hour?.
My suggestion is, the donor knows how much of particular goods are to be sent. In your system, the donor privately receives from the scheduled recipient of the goods the private sending address (which can be pre-created in your system and can be individual to each donor or shipment, in Bitcoin usually sending addresses are not easily visible until the transaction is sent which will be the last thing in this case). Then, the goods are shipped with a record of the donor receiving address attached. When the goods are received the recipient tallies the goods and sends x amount of the tally to the donor address using their previously provided secret sending address. The donor knows that the goods were receipted by the correct recipient and in what quantity. The donor has a proof of receipt for the delivery. All addresses can have various details attached at either end, details which can if necessary also be broadcast into the transaction pool for inclusion in your blockchain, separately or with the attached transaction, or when each address is created (just don't broadcast the recipient address when it is created until the transaction is sent!), or the details can remain private (transparency probably requires that most relevant details are published to the blockchain). Donors, recipients and your service each run the client node software and somewhere you have one or, as many as necessary miners. No one can steal the goods and report them correctly receipted and accounted for without knowing the private recipient sending address. You could even have the supply chain report progress to the donor receive address as the goods move at each step, secret addresses would not be necessary while the goods are in your control, just one sending address for each checkpoint in your control would permanently be enough I suppose and the addresses can be labelled or named if necessary with that data transmitted with the transaction at each checkpoint since you are not aiming for anonymity. The data would all be auditable. Block contents can be encrypted if privacy is required. This usage turns the terminology for sender and recipient around because they refer the 'receipt of goods message' that will later be sent.
... I don't know if that sounds useful?
What is involved? Programmers.
It may be possible to start directly with the Bitcoin Core client software and modify it for your use, sometimes it makes development quicker to pull apart a working model. I would not suggest a fork of the Bitcoin blockchain, build a new blockchain from the beginning.
Your intended use is certainly acheivable.


text:
Armory Ubuntu/Debian 0.96.0 signed with a different key than listed on the website
I downloaded the Armory version for Ubuntu/Debian from here:
https://www.bitcoinarmory.com/download/
Under the "Offline Signing Key" section it lists the public key for verification to be: 98832223.   This key is also used throughout their verification instructions.  They also show the fingerprint for this key on that page.
However, the files I downloaded are signed with key 4922589A.  I looked that key up on pgp.mit.edu and it shows the key owned by "goatpig (Offline signing key for Armory releases)"  Now, I see that goatpig is the name of one of the contributors on github, but really anyone can make a key with that name and since the website doesn't reference the key, or give me a fingerprint for the key, that I can find, I am hesitant to trust it.
My question here really is, can anyone confirm what the proper public key is to verify the armory downloads.  Did I miss something?
--update
I see there are two armory websites  www.bitcoinarmory.com and btcarmory.com.  each has a 0.96.0 download and the hash of both installs are the same, so I assume they are the same file, they are also both signed with the same public key.  The difference is that bitcoinarmory.com says to verify with 98832223 and btcarmory says to verify with 4922589A.  Very confusing, but my best guess is that  4922589A is actually the proper key to verify the signature with.  Either way, I think I'm just going to stick with bitcoin-qt unless someone can help clear this up.

https://bitcoinarmory.com is no longer Armory's official website. The official website is actually https://btcarmory.com. bitcoinarmory.com still hosts the new binaries, but they are only a mirror and everything else on the site is outdated.
Since Armory's development changed a few years ago, the actual release signing key is 4922589A as that is the new maintainer's signing key. This key is used on Armory 0.94.0 and above. The old signing key, 98832223, is the old maintainer's signing key.

According to this reddit thread and the comment below, the old Armory developers could no longer work on Armory and the project is maintained by a former employee.
https://www.bitcoinarmory.com/ is the website of the old project, is abandoned, but still has higher Google rank.
https://btcarmory.com/ is the website of the new project.
See Andrew Chow's answer for info about the keys.

There were no disagreements, just that ATI no longer had the ability to work on Armory and went out of business. One of their former employees began maintaining it and the change to the new maintainer (and new repo, etc.) was amicable and endorsed by Alan Reiner, the former maintianer.

OK, thanks, seems like I misunderstood, will edit the answer


text:
Can't understand arbitrage profit calculation
Found the formula in the following link. I can't understand with my knowledge. Can anybody explain me with an example?
profit = ExchangeA_sell * (1 - ExchangeA_fee) - ExchangeB_buy * (1 + ExchangeB_fee).

One more thing, Is this formula good for all exchanges? Cryptsy and Bter have calculated differently their net total. Bter sell offer is different from cryptsy sell offer. In Bter the trade fee is deducted just opposite to cryptsy in terms of buy and sell currency?

I explained it in more detail here. Maybe it is more clarifying

I'm not quite sure what you mean in the other questions. The net total does not matter at all for arbitrage. And what in the sell offer is different? The offers itself are of course different, because it are different exchanges. I tried to explain something similiar as your last question here. But please rephrase

@Mathias711 - http://bitcoin.stackexchange.com/questions/28263/calculation-of-arbitrage-profit. This is my problem. I am stuck at here.

I saw the question, I tried to read it, but important stuff came through. I will comment my first idea of it

As explained by http://www.investopedia.com/terms/p/profit.asp:

profit = total revenue - total expenses

or in plain English:
profit = (what you had received after selling all your coins) - (what you had paid to buy your coins)

so, for example:
If you had spent $1000 for Bitcoin priced at $500/BTC on exchange A, and say the fee is 1%, you will received
$1000/$500*(1-0.01) = 1.98 BTC

If you move and sell your 1.98 BTC at for $600/BTC on exchange B, which also charges a 1% fee, you will receive
1.98*$600*(1-0.01) = $1176.12

So your profit will be
$1176.12 - $1000 = $176.12

Remember to also subtract any withdrawal/deposit fees if applicable.


text:
How would one go about acquiring the HashofThingtoSign from this old transaction?
How would one go about acquiring the HashofThingToSign that is used in the "Signature Generation" equation for this example transaction such that it could easily also be applied to any other given pre-existing transaction?
Example Transaction: 82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653
Found at: https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653
This is made of the Raw Transaction:

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700

The input script is:

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01 03e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27

The Output scripts are:

OP_DUP OP_HASH160 43bd19b0436db26d24c789bebaee9a3b1b73cdd3 OP_EQUALVERIFY OP_CHECKSIG
OP_DUP OP_HASH160 aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a OP_EQUALVERIFY OP_CHECKSIG

The transaction that gave this wallet the coins that we are spending in this transaction is 6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1
Found at https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653
This previous transaction is made of the raw transaction:

0100000001e9cb57de3eac7ce6c703f8525c8c7cf87b064a18d7c830bc08901f776ef81e28010000006a4730440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb012102bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9feffffff028af81915000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac18176c00000000001976a91454abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f388aca1470700

The input script for this previous transaction is:

30440220090e1e73bfc2f37073f80f680893013fa40833e7a9dc7ed1667f728be72a75d302200d1b20fc0f3424f2a1e95f6f9c75a09260d2c889ff179e6dc1ec23423fd329bb01 02bbe30b55f53ce14af3f0e58a854941de58d91ad21da1169c6103327f4cd17ff9

The output script for this previous transaction are:

OP_DUP OP_HASH160 6ffdc2e9e69434a7832208db5a6148c67563e8ae OP_EQUALVERIFY OP_CHECKSIG
OP_DUP OP_HASH160 54abba8c9ffd25c9cf7c232bc3f3998a9c1fe4f3 OP_EQUALVERIFY OP_CHECKSIG

How and what would be the easiest path to determine the HashofThingtoSign in this transaction using the data supplied? (or do we need more data?)
The last step is obviously a sha-256 hashing of something.  What would the full text of that something be for this transaction that could simply be pasted into something such as http://www.movable-type.co.uk/scripts/sha256.html to produce the HashofThingToSign for this transaction?
What is this transaction's actual hash supposed to be as a result of the explained process (so that one can check one's work)?
Can we even determine what the hashofthingtosign was on this transaction without the privatekey?
Is the "hashofthingtosign" used in the signature generation simply the whole raw transaction "0100000001b1bbfd...7e6cd0100a88acb2480700" hashed with SHA-256 twice, i.e. the same as the transaction ID?
(1ecc3ee8e17966d90250cfe86a4b8e7b17a310bc18813a07b3c3e00b9c8b21b8 for this transaction)?
It has been proposed that this question is a duplicate to the question and or seeking a duplicate answer from How does the ECDSA verification algorithm work during transaction? . I am reading it in an attempt to fully discern if that is the case.  The difficulty in making sense thereof confirms it is NOT an answer I would accept as valid (as even the original person who asked that question commented they weren't sure of the answer being sufficiently clear such that they could understand it).  I can confirm it has some of the information.  At the very least, I can confirm, thus far, it appears to be missing the details of various steps (where pieces of data came from), uses terminologies that I cannot fully confirm their meaning as correlated with the answer I've received so far (it may be too advanced or casual terms used by someone with a very advanced understanding thereof).  I'm trying to combine the information from that question, the "How to redeem a basic TX?", and the answer I've been given so far. This new answer might contain the missing pieces to the puzzle, but it is not the ultimate answer.  If I can make sense of it and produce an answer, I will certainly provide that, but I am doubtful I will be successful as I still think there are too many missing pieces.

Possible duplicate of How does the ECDSA verification algorithm work during transaction?

The steps to generate the message for signing are given in the accepted answer here:
How to redeem a basic Tx? -
 specifically, step 1 to 14.
The transaction hash (txid) is not the same as the message to sign, because the hash is taken of the signed transaction including the scriptSig (which obviously can't sign itself), so we've got to make some small modifications to the transaction to get it into the format for signing
Let's get the raw transaction you gave in your question and break it down:

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000006b483045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d012103e5b9f0bb669b289efb8d2826487a24ef5f3985624c8bc3a3e34f6bd54e080b27feffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb2480700

You can obtain raw transaction data from blockchain using the rawtx keyword and add "format=hex": https://blockchain.info/rawtx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653?format=hex
Note that the following breakdown is a description of the data in that raw transaction, the only modifications needed are in bold.
Steps 1 and 2 are the same, we have the 01000000 version and the 01 number of inputs. Step 3 uses:

b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c

Which is the hash 6c002a15151a79d8163a03f4bc87b783a67bf0eeb18ff2b533e703317afdbbb1 (notice that the bytes are in reverse order) of the previous transaction whose output you are spending (https://blockchain.info/tx-index/269874933/0).
Then we have output index 0 from that transaction, i.e. 00000000, for step 4. This can be seen by looking at the previous transaction we are spending and seeing the index of the output we are spending.
Now for step 5 and 6, the transaction above contains the scriptSig, beginning with 6b to denote that the scriptSig is 107 bytes long, and then the 107 byte sig itself, 483...27. Pieter Wuille's answer here:  What are the parts of a Bitcoin Transaction "Input" script? is extremely good for explaining what the parts of the input script are. But for signing, bitcoin uses the scriptPubKey from the output being spent, so we have to replace that scriptSig (delete the scriptSig data from the transaction and insert instead) 19 to denote 25 bytes and then the 76a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88ac scriptPubKey itself from the previous output, very similar to the bytes used in step 5 and 6 because both are P2PKH outputs. Again this scriptPubKey can be found by looking at the previous transaction we are spending.
In step 7, this transaction uses the bytes feffffff which is the hexadecimal number 0xfffffffe. This sequence number is used as per BIP 125, meaning that the transaction is not opting in to being replaceable, but still uses locktime.
Then we have 02 to say there are 2 outputs in this transaction:

The first spends 7c8d370000000000, i.e. 0x378d7c = 3640700 satoshis, has a 19 byte script, which is 76a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388ac
The second spends c1bbe11400000000, i.e. 0x14e1bbc1 = 350337985 satoshis, also has a 19 byte script, which is 76a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88ac

Finally, we have the locktime of b2480700, i.e. 0x748b2 = block number 477362.
For signing we must then append 01000000 for SIGHASH_ALL to the end
This gives

0100000001b1bbfd7a3103e733b5f28fb1eef07ba683b787bcf4033a16d8791a15152a006c000000001976a9146ffdc2e9e69434a7832208db5a6148c67563e8ae88acfeffffff027c8d3700000000001976a91443bd19b0436db26d24c789bebaee9a3b1b73cdd388acc1bbe114000000001976a914aefaa9d79e3c62c3f0cc909a3aee327e6cd0100a88acb248070001000000

Which when hashed twice is 6823ba9770a496269a8f5368beec5ccb7b22ecd626265140be38aba1c8a25388 (note I haven't verified that this is correct yet, but it should be)

Comments are not for extended discussion; this conversation has been moved to chat.


text:
How to generate a valid bitcoin address for destroying bitcoins?
(Following up to this question.)
In order to put a bitcoin beyond use, the answer was to select a made up address. As this isn't a formal destruction of bitcoins, there's a risk that the private keys could be found to spend those "destroyed" bitcoins.
If someone suggests an address, people might suspect that this address was selected because that person painstakingly looked for an address that looked like a made up address.
How can an address for bitcoin destruction be selected that everyone can be reasonably sure no-one's going to know the private keys to spend the destroyed bitcoins?

Start with an invalid public key
Bitcoin addresses are the pubkeyhash (not pubkey) plus version and checksum information, encoded in base 58.
Bitcoin address = version + RIPEMD-160(SHA-256( Public Key )) + checksum

The steps for converting a public key to an address can be found here:
https://en.bitcoin.it/wiki/Address
Since the address uses the pubkeyhash not the actual pubkey we can exploit this by hashing an invalid pubkey (one which can't possibly exist) and thus produce a valid address from an invalid pubkey.
So to start we find an invalid public key.  All valid public keys begin with 0x04 if uncompressed and 0x02 or 0x03 if compressed.  A pubkey beginning with any other value is undefined and thus there is no possible signature that can be created to satisfy that key requirement.  Since spending coins requires signing the transaction with the correct private key, an address which has no known private key is unspendable.  By using a public key which is known to not have a private key others can confirm that no private key exists.
A valid Bitcoin public key (not address):

04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

An invalid public key

0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

There are other ways to produce a known invalid public key.  ECDSA keys must be exactly 65 bytes if uncompressed or 33 bytes if compressed so a key with a different length will also be invalid.  For uncompressed keys the y value must be correctly produced from the x value.  The point must also lie on the curve.  It also can't be above the modulus for the curve.  So there are a lot of ways to produce provably invalid keys but it best to choose one which is obviously invalid.  This is probably the simplest obviously invalid public key.

0x00

This public key is invalid for a number of reasons (not produced by private key multiplied by the generator, not located on the curve, not a valid point, but even simpler it doesn't have a valid prefix and is not the correct length).
The important thing is this isn't just some probably invalid key it is a provably invalid key.
You should test your invalid public key against the reference client to ensure the client reports it as invalid as well.  The validity of keys is a consensus issue so this will not change short of a hard fork.
Produce a valid (but unspendable) address from your invalid public key
You may wonder why we want the address to be valid.  All clients should validate addresses given by users to avoid accidental loss of funds.  So an invalid address is also unspendable but most users will find it impossible to send funds to the address.  A P2PkH address is the pubkeyhash with version and checksum information encoded in base58.
When you provide an address to a Bitcoin client it decodes the address back down to the 'raw' pubkeyhash.  So producing a valid address means starting with a valid pubkeyhash.  This isn't a problem because the hash of anything is a valid hash.  Clients don't know what pubkey is hashed to produce the pubkeyhash as the underlying pubkey is not provided and hashing functions are one way.
The Bitcoin network only verifies that an address is in the right form, length, and has the right checksum when "validating it".  Producing an address from a pubkey is beyond the scope of this question but there are utilities and the link above provides the steps.  The resulting pubkeyhash and encoded address will be seen as valid by the network and client but it requires a provably impossible private key to spend funds sent to that address.
Now with just the address (and decoded pubkeyhash) a user can't verify that the underlying pubkey is invalid so you should publish the raw pubkey along with the address.  Users can recreate the address using any bitcoin client or tool and will produce the same address you provide.  Users now have a trustless way to verify that the coins indeed are unspendable.  Any coins sent to the address can never be spent and are effectively destroyed.
Hash collision
Technically it is possible but improbable for more than one public key to have the same Bitcoin address. This is called a hash collision.  If public key p1 and public key p2 both hash to the same address A then privates keys for either of these public keys can spend the funds.  However the likely of this happening is very low.  Unless RIPEMD hash algorithm is broken the probability of finding two public keys which generate the same hash (Bitcoin address) is 1 in 2^160 which is far beyond our computational power to locate.
A few words on why you should use a 'Nothing Up My Sleeve' number:
Using a "nothing up my sleeve number" (such as a single zero, all zeroes, single repeating digit, sequential numbers, digits of pi, etc) is not required as any invalid public key is equally unspendable but it would improve public confidence that you haven't already found a collision (as improbable as that is).
If you just take a random invalid key like say:

00000fdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Some may question why you chose this specific key. The fear would be that you choose this key not randomly but because you have stumbled upon a collision between this key and a valid key.  There is no way to prove the key is random thus the fear will always remain.  Cryptographic functions (like RIPEMD or SHA-256) often use "nothing up my sleeve values" to provide security that a constant was not chosen to enable some cryptographic flaw or "backdoor" in the algorithm.  For example SHA-256 uses constants for the initial values of the block segments.  Technically these could be any random number but that would lead to concern that the 'random' number isn't actually random.  So SHA-256 uses first 32 bits of the fraction portion of the cube root of the first 8 prime numbers.  This allows verification when a pseudo random number is needed.  It is very unlikely there is some magical property between the fractional portion of the cube root of sequential prime numbers that undermines SHA-256.
http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number
Update (03/31/2015)
It is easier to do this now by using an OP_RETURN (null data) output and it doesn't bloat the UTXO with outputs that can't be spent but the network is unaware they can't be spent.  Any funds sent to an output which contains OP_RETURN are provably unspendable and the network will drop the output from the UTXO.  The UTXO (unspent tx output set) is a critical resources which is necessary for validating new transactions and blocks so destroying/burning coins using UTXO is a more responsible use of this shared resource.

I think there is an error in the formula in your first paragraph. As explained on this wiki page, only a single SHA-256 hash is used for generating the hash-160. For the checksum, however, (the first 4 bytes of) a double SHA-256 hash is used.

That is correct.  Fixed.

I've wrote a C# program that can be compiled and run easily, as well as a list of burn addresses at my blog: http://earlz.net/view/2014/10/22/0340/provably-spendable-altcoin-burn-addresses

Since you speak of a more responsible use of a shared resource, how can burning Bitcoin be seen as responsible? There is a finite number, each temporarily owned by some individual - it is easy to show that title to your property passes when you do. A company could not legitimately burn any Bitcoin that they possess any more than a company could burn cash - it is not in the best interest of the company. Burning Bitcoin rather than spending is no more responsible than burning your paycheck every week - you deprive yourself and the rest of the shared economy of the benefit when it is spent.

There are four basic ways, and they all work:

Come up with an address that passes the basic sanity checks but is internally invalid. You can know for sure that no key could possibly match this address.
Put strings of characters in the address that are way beyond what anyone could generate in a vanity address. For example, if the Bitcoin address has "FourScoreAndSevenYearsAgo" in it, it's clearly beyond anyone's capability to find a corresponding private key.
Use a public key that's obviously made up, such as one that consists only of zero bytes or that contains all consecutive digits of Pi. It's clearly beyond anyone's capability to find a corresponding private key. (For this one to work, you need to disclose the public key.)
Use a hash of the public key that's obviously made up. This works the same as the option above, but the difficulty would be in even finding a public key with such a hash, much less finding the corresponding private key.

Isn't point 1 technically wrong as DeathAndTaxes and ThePiachu have demonstrated? We can't know for sure that no one knows a valid key matching the address-hash since there's an infinite number of valid keys slotted into a limited amount of possible hash values.

@Pacerier The address would be internally invalid if we pick point 1. No key could match that address. You can slot an infinite number of things into a finite number of slots and still know for sure that some slots are empty. There are an infinite number of integers and a finite number of English words for categories, yet no integer falls into the category denominated by the word "angel".

If you want to use an address, it would be nice to generate an address that can be verified by a human as obviously unspendable just by looking at the Base58. When you look at these addresses, you will say, "wow, that is obviously unspendable."
1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- used by Counterparty
1ChancecoinXXXXXXXXXXXXXXXXXZELUFD <- used by Chancecoin
These addresses are characterized by a human-readable identifier at the start, followed by a large number of X's. In order to spend the funds from an address like this, you would need to first reverse the hash (impossible), then find the private key that corresponds to the public key that you got (also impossible).
Note that the last six digits of these addresses are Base58Check checksums. This is the only tricky part of the process: you need to search over about 4 billion strings until you find a valid Base58Check string. This will only take an instant, though. You can easily generate these addresses using adamkrellenstein/unspendable on GitHub.
Inspired by this other StackExchange answer.

If you want to be pretty sure nobody can retrieve the Bitcoins:

Look at the wiki article on Addresses.
Start at point 3 with an obviously fake number (like, "0000000000000000000000000000000000000000")
Continue with points 4-9.
You get a "valid" address for destroying Bitcoins.

What is the catch? As normally you'd generate the public key from a private key and hash it a couple times, in order to retrieve coins from the address you generated, one would have to find such a specific number in point 1, that after points 2 and 3 would generate your bogus number. The chance of you finding one is about 1 in 2^160, which is impossible at current computation speeds. The more orderly the number you used in point 3 is, the more people would believe that it is an obviously fake address.

The methods described by DeathAndTaxes are appropriate. The OP_RETURN method is clearly the best if you want to adhere to the bitcoin recommendations.
However, I would like to present an alternative method where you can provably burn coins and also include sufficient information in the address. We used this method in the first versions of OpenBazaar and it is called an "almost-collision coin burning".
The de facto standard for burning coin in bitcoin is through an OP-RETURN script. This script has the important advantage that it contributes to bitcoin’s network scalability, as it allows full nodes to prune their UTXO when proof of burn transactions are detected. The mechanism employed to achieve that is simple: While a UTXO is maintained for all unspent regular transactions, when an OP-RETURN transaction is received by a full node, the full node can avoid adding that transaction to the UTXO completely, as the OP-RETURN script constitutes a proof that the amount remains unspendable and hence no future transaction can attach this dangling output to its input; it is hence a permanent dangling output edge.
OP-RETURN scripts work by having the first operator of the bitcoin script be an OP-RETURN, indicating an immediate exception in the execution of the script, hence making spending impossible. After the initial OP-RETURN operator, the rest of the script data can contain information about why the coin was burned, so that different applications can demand different burning, and so that the association with an account is possible. For example, in OpenBazaar’s case, it is important to associate the burned amount with an OpenBazaar GUID, which can be included as non-executable code after the OP-RETURN. The fact that this code is non-executable follows from that it will never be executed due to the earlier exception. However, the OP-RETURN approach lacks certain usability properties that we wished to preserve in our OpenBazaar implementation. In particular, for simplicity of implementation and usage, as well as for separation of concern reasons, we decided that OpenBazaar does not need to include a bitcoin wallet implementation. Instead, the user can use any existing wallet software they wish. Hence, to make payments required by OpenBazaar, either for product purchases or for burn transactions, the user would have to utilize their wallet directly.
Today, wallets do not have the ability to create OP-RETURN scripts in any usable way. The only way to create burn transactions are through manual issuing of script commands by the user, which can be confusing or impossible to execute for an average user without a programming background. Furthermore, the OP-RETURN script must be associated with an OpenBazaar GUID, something that makes the inclusion of this ability in existing wallets harder. While a wallet software could offer an API to do that, we are not aware of such implementations just yet.
For these reasons, we designed an alternative mechanism for coin burning which uses simple standard pay-to-pubkey-hash transactions. These transactions are treated normally by the bitcoin full nodes, hence they are propagated as required. Furthermore, it is easy for regular wallets to create such transactions, and users can easily understand the process and make the payment without worrying that an unnecessary amount of money will be transferred and without requiring special programming knowledge.
Our schema for burning is based on the following cryptographic assumption, a resistance to an almost-collision: It is computationally infeasible to calculate two hash pre-image values x1, x2 such that:
||H(x1)- H(x1)|| < ε
Where the norm denotes the Hamming distance of two strings and ε is a small constant, in our case 1. This assumption is strongly supported by the fact that a hash function is cryptographically secure; if this equation did not hold, a collision would have been found, modulo one bit, which indicates the hash is broken up to almost all of its bits.
Under this assumption for H = RIPEMD160, our schema asks for the burner to take the ECDSA public key associated with their OpenBazaar identity and turn it into a bitcoin address by following the regular schema for 1-prefixed bitcoin addresses. Regular bitcoin addresses are generated from regular bitcoin ECDSA keys as shown in the standard bitcoin address generation algorithm.
To generate an address that is provably unspendable, the burner starts with their ECDSA OpenBazaar public key and applies the same process. However, the burner perturbates the first SHA256 hash by one bit before piping it to the RIPEMD160 hash. Specifically, they flip the last bit of the hash output. The rest of the process follows identically. Finally, the burner transfers the amount of coin they wish to burn to this generated address. I will now illustrate the properties of correctness, uniqueness, and security for this scheme.
Correctness. To verify the correctness of the burn, a third party performs the same transformation as the burner. They begin from the public ECDSA key of the OpenBazaar node whose trust they wish to verify and follow the bitcoin address generation process, applying the same perturbation as the burner after the SHA256 stage. Arriving at the final bitcoin address, the verifier then checks the blockchain for money that was sent to this address. This concludes that the burn an honest burner performs will be correctly verified by an honest verifier. (This is a significant advantage when compared to alternative schemes that do not contain why-burned information such as nothing-up-my-sleeve addresses.)
Uniqueness. Under the assumption that RIPEMD160 is hard to reverse and the fact that SHA256 is a cryptographically secure hash function, assumptions already made by bitcoin, the uniqueness of burn address for each OpenBazaar key follows directly.
Security. For this scheme to be secure, we must prove that the burned money cannot actually be spent by anyone. Indeed, if the money were spendable, the spender would have to know the private key associated with a public key which hashes to the perturbed SHA256 value. However, this would allow the generation of an almost-collision in RIPEMD160, as the public key that can be used for spending the burned money and the public key of the OpenBazaar identity would constitute pre-images of hashes that only differ by one bit. From the almost-collision resistance assumption, we conclude that this is computationally infeasible.
The almost-collision method of coin burning introduces scalability challenges for the bitcoin software. We were not concerned with such challenges in OpenBazaar for two reasons. First, we felt a failure for bitcoin to scale given the massive motivated community use of our primitive constitutes a security problem for bitcoin itself, which must be addressed without requiring players to behave fairly to the system. This is a problem for bitcoin, not OpenBazaar. If bitcoin is susceptible to denial-of-service attacks with such means, the use of bitcoin as a payment system must be reconsidered.
Second, most importantly because we support the bitcoin ecosystem and wish to provide suggestions for solving its scalability issues, they can in fact be eliminated if proof-of-burn transactions are accompanied by the pre-image before perturbation. The accompanying pre-image constitutes proof that the money is unspendable, similar to the way OP-RETURN scripts constitute proof of unspendability. As these pre-images will be publicly available on the OpenBazaar network, in case OpenBazaar becomes largely adopted, full bitcoin nodes can utilize the OpenBazaar network to detect prunable UTXO outputs which perform proof-of-burn through almost-collision pay-to-pubkey-hash scripts. Regardless, the optimizability of the payment network is of little concern to its financially motivated users and its technical implementation details remain an open research problem.
Overall, however, once the OP_RETURN method becomes a usable alternative, the other methods of burning should be eliminated for elegance and scalability.

You may generate address with vanitygen or vanitygen-plus, and ignore the private key. Read more about it here: https://en.bitcoin.it/wiki/Vanitygen
E.g.
$ ./vanitygen 1Love
Difficulty: 4476342
[48165 K/s][total 2080000][Prob 37.2%][50% in 21.2s]
Pattern: 1Love
Address: 1LoveRg5t2NCDLUZh6Q8ixv74M5YGVxXaN
Privkey: 5JLUmjZiirgziDmWmNprPsNx8DYwfecUNk1FQXmDPaoKB36fX1o

Just use the Address, don't save the Privkey.

This fails the "How can an address for bitcoin destruction be selected that everyone can be reasonably sure no-one's going to know the private keys to spend the destroyed bitcoins?" requirement. How do I know that you didn't save the private key, or remember it?

An alternative to generating an address is to use a valid address known to be almost impossible to retrieve coins from i.e. https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE.
This is a good as destroyed because if anyone could reverse engineer the private key for this address, then due to the vanity length, they could use the same method to reverse engineer the private key for any address. Or they were lucky in the same way as winning the lottery jackpot each week for a year is lucky.


text:
Do bitcoin miners actually make money

Possible Duplicate:
How can I compute mining profitability?

Do bitcoin miners like the one depicted in the video below with 24 server clusters actually profit from bitcoins at the current prices? Are the bit coin exchange rates high enough to cover their costs of electricity and hardware? And is there enough liquidity in the market to actually unload them?
Or are all these miners hoarding them in hopes the idea will take off in the future?
Bitcoin Mining Rig - 24 Machine Setup - 48Gh

How can I compute mining profitability? might interest you

vote to close: other questions show exactly how to compute profitability under various scenarios. Other than that it is speculation. Some bitcoin miners are mining at a loss, some for profit, some making a lot of money, some a little, etc.

@lemonginger I used to agree, but thinking about it a bit more, I think it's not really a bad question nor a duplicate.

Miners have about 26% profit at the moment, that's includes only cost of electricity vs bitcoins sell price.

Once you include the amortized cost of hardware that 26% goes away pretty quick. It's tough to estimate exactly how much that should eat up, though, since there aren't very good sources for MTBF of GPUs running at 100% 24/7.

whose cost of electricity? that's totally variable....

Serith's answer has a good approximation for the operating costs. On that website, you can also see that miners have negative profits if you include hardware/bandwidth costs.
So it is profitable to mine, but it is not profitable to invest in mining hardware right now. Of course that these numbers often change according to several factors - BTC prices, mining difficulty, hardware updates, etc.
As for liquidity, MtGox alone moves around 1 million coins each month so that shouldn't be a problem (the total monthly bitcoin production is ~216000 until next year).

At current valuations ($5.59 as I write this), the profitability of GPU mining is dominated by the cost of physically housing, cooling, and maintaining the GPU mining rigs in a commercial scale datacenter. Electricity and rig capital costs are both less. Electricity and GPU hardware depreciation costs are generally the only costs considered in today's mining profitability calculators.
Our analysis can be found here.


text:
How should you backup your wallet?

How often? Is backing it up once enough?
Any best practices to storing the backup?

See related but not identical: http://bitcoin.stackexchange.com/questions/28/how-can-i-keep-my-wallet-secure

The file you'll need to back up is wallet.dat which can be found in %appdata%\roaming\bitcoin on Windows or ~/.bitcoin on Linux/MacOSX.
By default a pool of 100 pre-generated, unused addresses is maintained in your wallet, and so it is safe to use 100 new addresses without backing up your wallet.  New addresses are used most times you send bitcoins and used as a "change" address, and also when you request a new receiving address. As you use new addresses, more are generated and added to the end of the pool.  Once you've used 100 since backing up, you'll start using addresses which aren't in the backup. To this end, the frequency of your backups is largely determined by the frequency of your transactions and this is largely a personal decision. If you absolutely cannot manage a backup every 100 transactions (why?) or are comfortable with a more aggressive schedule (and smaller wallet) there is a -keypool option to change the number of addresses pre-generated.
Best practices for storing wallet backups almost always include encryption. Most folks in the community swear by tools like TrueCrypt for such purposes, though there are countless alternatives. Storage of the backup depends largely on how long-term the storage is intended to be and the security levels necessary. For small amounts of coin and short-term backups, online services like DropBox or Mozy might be adequate, assuming the wallet is encrypted before uploading. For longer-term or higher security backup, coins might be sent to an offline wallet stored in paper form at a physically secured location or any variation between.
Regardless of your wallet backup methodology and schedule, it is ALWAYS a good idea to take some basic measures to secure your wallet.

Aren't addresses generated in chunks of about a 100 and cached? So, you should only backup every ~50 transactions.

You're correct, amending my answer.

Until we get deterministic wallets, then backing up once is enough.

Even with the deterministic wallets we sort of already have backing up once is enough so long as you never perform any sends. Basically the tech we have in that arena is adequate for "savings" type accounts, but we're not there yet for "checking" type accounts.

The keypool isn't generated "in blocks of 100 addresses", it's maintained at 100 addresses.  Every time you use one of the 100, another is generated to replace it.

This answer could do with updating to mention that the standard client can now encrypt the wallet.

I just read this answer and it was like I was reading some alien language... Can someone please explain this for the non technical person?  i.e. if I backup my .dat file and only receive bitcoins with it and never send, will that single backup last forever?

Encrypted; to more than one place convenient to you: hard drive, pendrive, cloud. Some store it on paper but that's another school.


text:
What does BIP mean?
There is a lot of reference to BIP 16, 17 and the likes. What does BIP actually stand for? I'm unsure if this is a programming reference or a Bitcoin specific reference; either way I'm stumped.

BIP = Bitcoin Improvement Proposal. The suggestion to use the concept of BIPs is BIP 1.

Yes, BIPs are both a Bitcoin specific and a general programming reference as they were designed after the Python Enhancement Proposal (PEP)
throughout any open source project you are likely to see PEPs and PIPs, HIPs, and even Ethereum Request for Comments (ERC) that all essentially play the same role of helping a distributed group of people work in an organized fashion.


text:
I am reinstall my btc but balance and address not oldone?
hello sir I have getting some problem to my bitcoin client.
I am backup of my old wallet.dat and again install the btc client but this new client my old address is not showing and also my balance of old wallet $3.99 is where gone........
pls. check my balance and help me for solving this problem
http://blockexplorer.com/address/149ZUavxLWurrVkeXBJsh7X7gELB7i9PuP
Pls. help me sir what can i do
thanks

Did you finish downloading the block chain?

With the Bitcoin.org client, the balance is calculated based on data in the blockchain data files.  If those files haven't finished updating, the calculation will not be current.
The way to check on this depends on which version of the Bitcoin.org client you are using.  The most recent versions (v0.6.x) will show the status at the bottom.  If is says "Synchronizing with network ..." then your balance may not show correctly until it has completed successfully.  When it is completed then a green check-mark will show in the bottom right-hand corner of the client.


text:
ElectrumX method blockchain.address.get_balance removed, how to get the script hash of a public addres and get balance?
Reading the ElectrumX documentation, found that the method for getting balance of any public address was: blockchain.address.get_balance, but was removed. Now, I understand that blockchain.scripthash.get_balance is the way for getting balances for any public address, but it requires a "scriphash".
Checking documentation for Script Hashes shows stepts for hashing the address to get script hash.
With this python code, I can get the electrum server data:
import json
from time import sleep

port = 50001
host = '127.0.0.1'

content = {
    "method": "blockchain.scripthash.get_balance",
    "params": ["af6df685465a42b753bf72dfdf36c43ea3c2931025411940609da6f2404b00c4"], # this is a tx_hash
    "id": 0
}

def electrumx(host, port, content):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))
    sock.sendall(json.dumps(content).encode('utf-8')+b'\n')
    sleep(0.5)
    sock.shutdown(socket.SHUT_WR)
    res = ""
    while True:
        data = sock.recv(1024)
        if (not data):
            break
        res += data.decode()
    print(res)
    sock.close()

electrumx(host, port, content)

With a transaction hash, it throws some results, not exactly the balance of any address involved:
{"id":0,"jsonrpc":"2.0","result":{"confirmed":0,"unconfirmed":0}}

My questions are:

What means "script hash" of a public address?
Is required to use a transaction hash, like in the code?
Why when using tx hash always shows "result":{"confirmed":0,"unconfirmed":0}
even if the address has funds.
Can the script hash be obtained just from a public address?

Thank you very much.

Well, it's been a long time, but I've been able to find a way by myself.
The python function for getting script hash is this:
from pycoin.symbols.btc import network
import hashlib
def get_script_hash(addr):
    script = network.parse.address(addr).script()
    return hashlib.sha256(script).digest()[::-1].hex()

And the full code to check the balance of a public address from a local electrum server is:
import socket
import json
from time import sleep
from pycoin.symbols.btc import network
import hashlib

port = 50001
host = '127.0.0.1'

def get_script_hash(addr):
    script = network.parse.address(addr).script()
    return hashlib.sha256(script).digest()[::-1].hex()

def electrumx(host, port, content):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))
    sock.sendall(json.dumps(content).encode('utf-8') + b'\n')
    sleep(0.5)
    sock.shutdown(socket.SHUT_WR)
    res = ""
    while True:
        data = sock.recv(1024)
        if not data:
            break
        res += data.decode()
    print(res)
    balance = eval(res)['result']
    print(f'{addr} has {balance["confirmed"] / 100000000} confirmed bitcoins')
    print(f'{addr} has {balance["unconfirmed"] / 100000000} unconfirmed bitcoins')
    sock.close()

if __name__ == "__main__":
    addr = "1x8cQ1gKJ5dwBRr1mjsYfsJbWBHJDnxg9"
    script_hash = get_script_hash(addr)
    content = {
        "method": "blockchain.scripthash.get_balance",
        "params": [script_hash],
        "id": 0}
    electrumx(host, port, content)

Thank you.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What happened with MtGox on 2011/9/12?
On that date, some erratic out-of-spread trades appeared on MtGox.
The explanation given says that accounts may have been compromised by the CosbyCoin attack on bitcointalk.org. I do not understand how this can lead to out-of-spread orders being executed.
He says the issue is resolved and proceeds to give us a speech about password security and says that we should keep trading "in confidence".
That does not satisfy me at all.

The actual quote is: trades can now be conducted in full confidence.  "Full"?  That seems arrogant, given the history.  But I acknowledge that their job is very very hard since there is no such thing as "full security"....

I do acknowledge they have a very hard job. I'm also not complaining about the problem itself, I'm complaining about the lack of explanation as to what exactly happened. I don't like being in the dark.

Some more info by upb from #mtgox:

<upb> so there IS some underlying bug which was triggered that caused invalid order matching
<@MagicalTux> yes, but it requires a large amount of funds to be triggered
<@MagicalTux> normal users, unless millionaire, wouldn't trigger it
<upb> must be some kind of integer overflow ;-)
<@MagicalTux> it happens when an order executes way too many orders at once
<@MagicalTux> I'm adding some code to avoid this from happening, but nobody in their right mind would do that

This actually reminded me of about 2-3 Weeks ago when I noticed a bug and reported it on #mtgox.
The bug worked as follows:

I had a buy order at, let's say 1 BTC for USD 10.0, last trade was 10.001
someone partly filled that order, let's say he filled 0.3 BTC
this had the effect of my order being in state "pending" with 0.7 BTC for USD 10.0
while my order was pending, a lower order (say at USD 9.99) was filled

I complained and a short while after, MagicalTux said he found the problem and fixed it.
I don't know if this could have anything to do with the current problem, but "it happens when an order executes way too many orders at once" sound kind of like this could be the case.
I also remember someone suggesting this above bug could be exploited to disable a lot of orders in order to "get to" an order that would normally be well out of spread. Maybe someone managed to pull off this exploit. That would also match MagicalTux saying something about 2000 accounts being created. Maybe these accounts were used to "disable" orders by filling a small part of them successively in order to execute an order well out of spread.


text:
Is it possible to recover stolen funds from the scammers wallet?
Im a victim of a bitcoin scam.
The scammers gave me a fake wallet address and stole all my USDT.
Since im new here im trying to increase my reputation to be able to comment and ask questions to specific users.
Im looking for blockchain experts to help me with my situation.
Thank you very much for your help!

Does this answer your question: How do I recover from a cryptocurrency scam. or Can bitcoins be traced to scammers

yes, it does. thank you very much for your help


text:
Bitcoin fails to compile with Boost
After running 'autogen.sh', './configure' and then 'make', I keep getting the following error:
Undefined symbols for architecture x86_64:   "__ZN5boost10filesystem4path5imbueERKSt6locale", referenced from:       __Z16SetupEnvironmentv in libbitcoin_util.a(libbitcoin_util_a-system.o) ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [bitcoind] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1
I was told that boost is clang compiled and thus, GCC incompatible, so I've been trying to recompile boost with GCC via:

HOMEBREW_CC=gcc-10 HOMEBREW_CXX=g++-10 brew install --build-from-source boost --HEAD
`brew install boost --build-from-source --HEAD'

Both of these commands throw the following patching error though:
==> Patching ==> Applying 7b3fc734242eea9af734d6cd8ccb3d8f6b64c5b2.patch patching file boost-install.jam Hunk #1 FAILED at 483. 1 out of 1 hunk FAILED -- saving rejects to file boost-install.jam.rej
Any idea how to fix this problem and successfully recompile boost? Please let me know!
EDIT: For clarification, I'm trying to build Bitcoin Core v0.21.0 on macOS Catalina version 10.15.7
UPDATE:
Finally got this working - turned out I had an outdated version of gcc installed via MacPorts, in addition to Apple's default compiler, which seemed to have been interfering with things. Once I uninstalled MacPorts, everything started working smoothly if I configured with --with-gui=no

Provide more details:
What is your OS ? Which version ? Are you cross-compiling ? If yes, on which system? For which system ?

@Gladiator9120 Thanks for the reply -  I'm running on macOS Catalina version 10.15.7, and I'm compiling with gcc-10, don't believe I'm cross-compiling but I'm new to this so I may be wrong. If it helps, I've been configuring bitcoin-core with this command: ./configure CXX=g++-10 CPP=cpp-10 CC=gcc-10

Alternatively you could do make in the depends folder in core then configure again this would compile the dependencies. I cant get brew's boost to compile with gcc either.

Appreciate you trying! And I'll try that now - do I still run ./configure CXX=g++-10 CC=gcc-10 before running make in the depends folder?

And do I need a --prefix= arg when I configure again?

It may help if you also included which version of Bitcoin Core you're trying to build.

@Murch Will add that - I'm trying to build v0.21.0

Depends doesn't need prefix. every time you use configure use it as CXX=g++-10 CC=gcc-10 ./configure your order might work too however i'm not sure if that works.

Ok awesome, I'll try this and let you know how it goes

Got it working - turned out I had an outdated version of gcc installed via MacPorts in addition to Apple's default compiler which seems to have been interfering with things. Once I uninstalled MacPorts, everything started working smoothly if I configured with --with-gui=no

I just had this problem happen...  On Mac OS 12.4, I installed boost with homebrew, and it was installed to /opt/homebrew/Cellar/boost/1.82.0_1
When I ran ./configure I got:
checking whether the Boost::System library is available... no
checking whether the Boost::Filesystem library is available... no
checking whether the Boost::Program_Options library is available... no
checking whether the Boost::Thread library is available... no
checking whether the Boost::Chrono library is available... no
checking whether the Boost::Unit_Test_Framework library is available... no
checking for dynamic linked boost test... no
checking for mismatched boost c++11 scoped enums... ok
configure: error: No working boost sleep implementation found.

So I added the with-boost flag with that path: ./configure --with-boost=/opt/homebrew/Cellar/boost/1.82.0_1
And then it worked.  But running make failed for various reasons such as missing import statements, std::placeholder conflicting with boost::placeholder and other reasons...  So I had to make the following changes:
diff --git a/src/httpserver.cpp b/src/httpserver.cpp
index e1763c6ad..66390c4e3 100644
--- a/src/httpserver.cpp
+++ b/src/httpserver.cpp
@@ -16,6 +16,7 @@
 #include <stdlib.h>
 #include <string.h>

+#include <deque>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <signal.h>

diff --git a/src/miner.h b/src/miner.h
index 3ba92b16b..993bde682 100644
--- a/src/miner.h
+++ b/src/miner.h
@@ -73,7 +73,7 @@ struct modifiedentry_iter {
 // except operating on CTxMemPoolModifiedEntry.
 // TODO: refactor to avoid duplication of this logic.
 struct CompareModifiedEntry {
-    bool operator()(const CTxMemPoolModifiedEntry &a, const CTxMemPoolModifiedEntry &b)
+    bool operator()(const CTxMemPoolModifiedEntry &a, const CTxMemPoolModifiedEntry &b) const
     {
         double f1 = (double)a.nModFeesWithAncestors * b.nSizeWithAncestors;
         double f2 = (double)b.nModFeesWithAncestors * a.nSizeWithAncestors;
@@ -88,7 +88,7 @@ struct CompareModifiedEntry {
 // This is sufficient to sort an ancestor package in an order that is valid
 // to appear in a block.
 struct CompareTxIterByAncestorCount {
-    bool operator()(const CTxMemPool::txiter &a, const CTxMemPool::txiter &b)
+    bool operator()(const CTxMemPool::txiter &a, const CTxMemPool::txiter &b) const
     {
         if (a->GetCountWithAncestors() != b->GetCountWithAncestors())
             return a->GetCountWithAncestors() < b->GetCountWithAncestors();

diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 3ec1a1c27..54a6c5f36 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -31,6 +31,7 @@
 #include "validationinterface.h"

 #include <boost/thread.hpp>
+#include <array>

 #if defined(NDEBUG)
 # error "Bitcoin cannot be compiled without assertions."

diff --git a/src/test/cuckoocache_tests.cpp b/src/test/cuckoocache_tests.cpp
index 00446aa11..29bc0acc7 100644
--- a/src/test/cuckoocache_tests.cpp
+++ b/src/test/cuckoocache_tests.cpp
@@ -7,6 +7,7 @@
 #include "random.h"
 #include <thread>
 #include <boost/thread.hpp>
+#include <deque>

 /** Test Suite for CuckooCache

diff --git a/src/txmempool.h b/src/txmempool.h
index db1a02455..05d68b645 100644
--- a/src/txmempool.h
+++ b/src/txmempool.h
@@ -229,7 +229,7 @@ struct mempoolentry_txid
 class CompareTxMemPoolEntryByDescendantScore
 {
 public:
-    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b)
+    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b) const
     {
         bool fUseADescendants = UseDescendantScore(a);
         bool fUseBDescendants = UseDescendantScore(b);
@@ -251,7 +251,7 @@ public:
     }

     // Calculate which score to use for an entry (avoiding division).
-    bool UseDescendantScore(const CTxMemPoolEntry &a)
+    bool UseDescendantScore(const CTxMemPoolEntry &a) const
     {
         double f1 = (double)a.GetModifiedFee() * a.GetSizeWithDescendants();
         double f2 = (double)a.GetModFeesWithDescendants() * a.GetTxSize();
@@ -266,7 +266,7 @@ public:
 class CompareTxMemPoolEntryByScore
 {
 public:
-    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b)
+    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b) const
     {
         double f1 = (double)a.GetModifiedFee() * b.GetTxSize();
         double f2 = (double)b.GetModifiedFee() * a.GetTxSize();
@@ -280,7 +280,7 @@ public:
 class CompareTxMemPoolEntryByEntryTime
 {
 public:
-    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b)
+    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b) const
     {
         return a.GetTime() < b.GetTime();
     }
@@ -289,7 +289,7 @@ public:
 class CompareTxMemPoolEntryByAncestorFee
 {
 public:
-    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b)
+    bool operator()(const CTxMemPoolEntry& a, const CTxMemPoolEntry& b) const
     {
         double aFees = a.GetModFeesWithAncestors();
         double aSize = a.GetSizeWithAncestors();
@@ -656,7 +656,7 @@ public:

     /** Estimate priority needed to get into the next nBlocks */
     double estimatePriority(int nBlocks) const;
-
+
     /** Write/Read estimates to disk */
     bool WriteFeeEstimates(CAutoFile& fileout) const;
     bool ReadFeeEstimates(CAutoFile& filein);
@@ -705,7 +705,7 @@ private:
     void removeUnchecked(txiter entry, MemPoolRemovalReason reason = MemPoolRemovalReason::UNKNOWN);
 };

-/**
+/**
  * CCoinsView that brings transactions from a memorypool into view.
  * It does not check for spendings by memory pool transactions.
  */

diff --git a/src/validation.cpp b/src/validation.cpp
index fe8f8365b..6dcd1f0c4 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -170,6 +170,7 @@ private:

 public:
     MemPoolConflictRemovalTracker(CTxMemPool &_pool) : pool(_pool) {
+        using namespace boost::placeholders;
         pool.NotifyEntryRemoved.connect(boost::bind(&MemPoolConflictRemovalTracker::NotifyEntryRemoved, this, _1, _2));
     }

@@ -180,6 +181,7 @@ public:
     }

     ~MemPoolConflictRemovalTracker() {
+        using namespace boost::placeholders;
         pool.NotifyEntryRemoved.disconnect(boost::bind(&MemPoolConflictRemovalTracker::NotifyEntryRemoved, this, _1, _2));
         for (const auto& tx : conflictedTxs) {
             GetMainSignals().SyncTransaction(*tx, NULL, CMainSignals::SYNC_TRANSACTION_NOT_IN_BLOCK);
diff --git a/src/validationinterface.cpp b/src/validationinterface.cpp
index d4121a28b..3b89b1c2c 100644
--- a/src/validationinterface.cpp
+++ b/src/validationinterface.cpp
@@ -12,6 +12,8 @@ CMainSignals& GetMainSignals()
     return g_signals;
 }

+using namespace boost::placeholders;
+
 void RegisterValidationInterface(CValidationInterface* pwalletIn) {
     g_signals.UpdatedBlockTip.connect(boost::bind(&CValidationInterface::UpdatedBlockTip, pwalletIn, _1, _2, _3));
     g_signals.SyncTransaction.connect(boost::bind(&CValidationInterface::SyncTransaction, pwalletIn, _1, _2, _3));

and now I can run make and it works and built bitcoind and bitcoin-cli

The src/miner.h file doesn't exist anymore since Bitcoin Core v23.0; what version are you trying to compile?

Also, CompareModifiedEntry doesn't exist anymore since 0.16.0, released in 2018.

Wow, my git must have gotten into a weird state..  I was on master and had fetched / reset hard, but apparently had files from older commits, so I just deleted everything and re-cloned bitcoin and looks like most of those problems are resolved, except I am getting test/fuzz/http_request.cpp:12:10: fatal error: 'event2/buffer.h' file not found despite having libevent installed at /opt/homebrew/Cellar/libevent/2.1.12_1 ...  Was not sure how to get around that other than to perhaps reconfigure with --disable-tests

Sorry, I'm not familiar with MacOS building. Have you read the doc/build-osx.md file?


text:
can i mine any cryptocurrency in my pc
i need help to see that if my pc can mine any cryptocurrency.
my spces:
Windows 7 Ultimate SP1
i3 2100 3.10GHz
AMD Radeon HD 6450
3gb Ram
If anyone needs more info about my pc they can tell me about what they want to know.

you can mine, I think you should look over to some places where you could mine.

probably one of the most popular would be Nicehash.

There are several calculators on the internet, also a nicehash calc which you could use.
Beside nicehash, there is a ton of renting pages and mining pages. Check them out to find what you are looking for. I also like https://www.miningrigrentals.com/ (when I was mining, I dont anymore).

but after downloading the nicehash miner in the device column it is not showing anything

Please read their Getting Started. Everything is explained there very well, including which software and how to use it.


text:
Does ad hoc adoption of private blockchains make the financial system vulnerable to tampering?
The security of a blockchain network depends on how many nodes are participating in that network. More number of participating nodes, implies better security. Currently, many financial institutions are integrating  a "private" blockchain into their operations. Since the number of participating nodes in a private blockchain is likely to be far smaller than the public blockchain, does it mean that it is easier to tamper the private blockchain? If that is true, then does it imply that ad hoc private networks of blockchain adopted by financial institutions will be less secure than a big public blockchain network?

this has the risk of getting a philosophical debate... Generally, the bitcoin blockchain was invented, to avoid, that malicious participants have no impact on the overall distribution of messages in the public network (aka tx with Satoshis in blocks). Along with some privacy features. So when someone creates a private blockchain, we are down to the level of trust. You can use a 1:1 copy of the bitcoin network, and don't go public. Then you compare the code to the executables, and can be sure, noone wants to tamper with it. But as it is private, you never know, how many "good" and how many "bad" nodes were invited to participate. There are use cases for private blockchains, when it comes to tx handling between several companies, which should be tamper proof. Question is, if the bitcoin blockchin is the right tool for this. In general I support your point of view, that private blockchains are less secure than a big public network. Trust is then based on the fact, that this company will not go bankrupt (or controlled by governments), and the privacy question remains unanswered, of course.


text:
Is there a simple python script for xpub generation from private key
I need a python script to verify, in an air gapped system, that my 24-word (or 12-word) mnemonic seed indeed generates the xpub that my wallet is showing me.
Is there a simple script that does that, having minimal dependencies?
UPDATE:
based on the answer below using https://github.com/trezor/python-mnemonic, I did
def main() -> None:
    import sys
    m = Mnemonic("english")
    seed = Mnemonic.to_seed("my 12 words")
    pubkey = Mnemonic.to_hd_master_key(seed)
    print(pubkey)

but I get
xprv...

and no pubkey.
How do I get the master pub key?

Using this library which is a pure python library with no dependencies (disclaimer: I am the author)
>>> from cryptotools import Xprv

>>> xprv = Xprv.from_mnemonic('assist excess fox blossom trouble cry must segment arrive stereo weather april pudding tuna change')

>>> xpub = xprv.to_xpub()

>>> xpub.encode()
'xpub661MyMwAqRbcGSaJ8ymCnwWbZzUgRB9XSAGoAvJc92oorJqzfyTPNQCEzqetVjofVs6DjXEPgR62vGP8UsSL4HFXLcRHdBbcDZ7DgyZea59'

is it possible to convert the xpub to ypub and zpub?

@GuerlandoOCs yes try adding the parameter addresstype='P2WPKH-P2SH' or addresstype='P2WPKH' in the from_mnemonic() method

shouldn't the method to_xpub be called to_pubkey then? xpub is a little misleading

I'm getting cannot import name 'Xprv' from cryptotools on my raspberry pi. Any thoughts on that? Thank you very much

Did you install the wrong library perhaps? Dont do pip install cryptotools thats a different kibrary

I cloned from git and placed into the raspberry pi sd card to later install it, there's no internet on the rpi

The following code using the python-bip32 lib can show this information.
from bip32 import BIP32, HARDENED_INDEX

bip32 = BIP32.from_seed(bytes.fromhex("01"))

# get master xpriv and xpub
master_xpriv = bip32.get_master_xpriv()
master_xpub = bip32.get_master_xpub()

print("master_xpriv: " + master_xpriv)
print("master_xpub: " + master_xpub)

# get from specif path
xpriv_from_path = bip32.get_xpriv_from_path("m/84'/0'/0'/0/1")
xpub_from_path = bip32.get_xpub_from_path("m/84'/0'/0'/0/1")

print("xpriv_from_path: " + xpriv_from_path)
print("xpub_from_path: " + xpub_from_path)

Yes, I'd say the simplest way is to use python bip39 implementation of trezor, this one file should be enough with methods:
to_seed - to convert list of the words into seed and
to_hd_master_key - to generate master xpub/xpriv
It doesn't support further derivations (which require a bit more dependencies), for which I'd suggest using bip32 library.

I did  def main() -> None:     import sys     m = Mnemonic("english")     seed = Mnemonic.to_seed("my 12 words")     pubkey = Mnemonic.to_hd_master_key(seed)     print(pubkey)

but I got only xprv9s2.... What am I missing?

I did an update, please take a look

I think it does not generate master pubkey, only priv key.


text:
How to get address from scriptSig?
I'm looking for a way to get address from scriptSig. I want to know input address. Can you share how to do it?
I prefer PHP library but any ways would be appreciated.
e.g.
I use bitwasp, a PHP library. I can see a scriptSig ("483...767") in vin. I want to decode it so that I can get the source addresses.
PHP sample
<?php

require_once 'vendor/autoload.php';

use BitWasp\BitcoinLib\RawTransaction;

$hex = '0100000001e7bb795fa90136f4052a99a433a16d71406261dec7eaff2a2a03ce7254bb4159010000006b483045022100f5b10c765ae5116917ddf9b8c4e8d07996b37ad934c005396e7dcda70e7621ee022014cf65f5cc46e229fbcfe7259b3f8c9d0b0c3cd446c4307a8872ad6cc0d538b401210396f8781a4900372a5d72d84718d146170d5983e67dff8b4a28fef80690c09767ffffffff035f150000000000001976a9143e37de641b25616304415a72bc556824f442004588ac00000000000000001e6a1c54f55fe6f2a0f349e2921d06e63d58712a906fbb4231f1e943da82d6313d1300000000001976a9142f7dcdf7cda481fe0f123d4c62bf830605e9f54d88ac00000000';

$tx_data = RawTransaction::decode($hex);
print(json_encode($tx_data));

Output
{
   "txid":"55a8f0d5852745ab2d80358ff4ae6fdbfeab0e4dc94b3474d1c5538e0579bb95",
   "version":"1",
   "vin":[
      {
         "txid":"5941bb5472ce032a2affeac7de616240716da133a4992a05f43601a95f79bbe7",
         "vout":1,
         "scriptSig":{
            "asm":"3045022100f5b10c765ae5116917ddf9b8c4e8d07996b37ad934c005396e7dcda70e7621ee022014cf65f5cc46e229fbcfe7259b3f8c9d0b0c3cd446c4307a8872ad6cc0d538b401 0396f8781a4900372a5d72d84718d146170d5983e67dff8b4a28fef80690c09767",
            "hex":"483045022100f5b10c765ae5116917ddf9b8c4e8d07996b37ad934c005396e7dcda70e7621ee022014cf65f5cc46e229fbcfe7259b3f8c9d0b0c3cd446c4307a8872ad6cc0d538b401210396f8781a4900372a5d72d84718d146170d5983e67dff8b4a28fef80690c09767"
         },
         "sequence":4294967295
      }
   ],
   "vout":[
      {
         "value":"0.00005471",
         "vout":0,
         "scriptPubKey":{
            "asm":"OP_DUP OP_HASH160 3e37de641b25616304415a72bc556824f4420045 OP_EQUALVERIFY OP_CHECKSIG",
            "hex":"76a9143e37de641b25616304415a72bc556824f442004588ac",
            "type":"pubkeyhash",
            "reqSigs":1,
            "hash160":"3e37de641b25616304415a72bc556824f4420045",
            "addresses":[
               "16fypikbjmmfroCHUhDLhczngCfL6BgccH"
            ]
         }
      },
      {
         "value":"0.00000000",
         "vout":1,
         "scriptPubKey":{
            "asm":"OP_RETURN 54f55fe6f2a0f349e2921d06e63d58712a906fbb4231f1e943da82d6",
            "hex":"6a1c54f55fe6f2a0f349e2921d06e63d58712a906fbb4231f1e943da82d6",
            "message":"unable to decode tx type!"
         }
      },
      {
         "value":"0.01260849",
         "vout":2,
         "scriptPubKey":{
            "asm":"OP_DUP OP_HASH160 2f7dcdf7cda481fe0f123d4c62bf830605e9f54d OP_EQUALVERIFY OP_CHECKSIG",
            "hex":"76a9142f7dcdf7cda481fe0f123d4c62bf830605e9f54d88ac",
            "type":"pubkeyhash",
            "reqSigs":1,
            "hash160":"2f7dcdf7cda481fe0f123d4c62bf830605e9f54d",
            "addresses":[
               "15L7U55PAsHLEpQkZqz62e3eqWd9AHb2DH"
            ]
         }
      }
   ],
   "locktime":"0"
}

Update 1
The following is a screenshot of blockchain.info

https://blockchain.info/ja/tx/10857ad56f1695559562af8076aea4ccba625ba79a82f75e5658c0c2fa4336c0
I'm wondering how I can get the source address "1J16FUpZsS6My1FqHXpka5fztAnyFsBPf1".

Update 2
I found a similar question and retrieving previous transaction was proposed. It may work but I want to decode hex so that it can reduce cost to access bitcoind.
How to get the Input Address from vin where only a txid is given (Insight-Api)

Update 3
This is also taking same approach. It may impossible to decode the scriptsig...
How to findout the sender of a transaction

Update 4
This explains why it is impossible. Okay I give up decoding scriptsig. I'll retrieve it by txid.

Due to the nature of the pay-to-pubkey script, the script sig does not contain the pubkey anymore (just the signature).

https://stackoverflow.com/questions/29350766/extract-input-address-from-a-namecoin-transaction-given-a-name-operation

Update 5 (Solved)
theStack gave me the best answer. Following the answer, I tried it in PHP with Bitwasp.
<?php

require_once 'vendor/autoload.php';

use BitWasp\BitcoinLib\BitcoinLib;
use BitWasp\BitcoinLib\RawTransaction;

$hex = '0100000001e7bb795fa90136f4052a99a433a16d71406261dec7eaff2a2a03ce7254bb4159010000006b483045022100f5b10c765ae5116917ddf9b8c4e8d07996b37ad934c005396e7dcda70e7621ee022014cf65f5cc46e229fbcfe7259b3f8c9d0b0c3cd446c4307a8872ad6cc0d538b401210396f8781a4900372a5d72d84718d146170d5983e67dff8b4a28fef80690c09767ffffffff035f150000000000001976a9143e37de641b25616304415a72bc556824f442004588ac00000000000000001e6a1c54f55fe6f2a0f349e2921d06e63d58712a906fbb4231f1e943da82d6313d1300000000001976a9142f7dcdf7cda481fe0f123d4c62bf830605e9f54d88ac00000000';

$tx = RawTransaction::decode($hex);

$asm = explode(' ', $tx['vin'][0]['scriptSig']['asm']);
$address = BitcoinLib::public_key_to_address($asm[1], '00');

print($address); // 15L7U55PAsHLEpQkZqz62e3eqWd9AHb2DHyusaku

The scriptSig needed for spending a P2PKH output (that is, an output of a standard address starting with '1...') consists of two parts, namely the signature and the public key. Looking at your example transaction 10857ad56f1695559562af8076aea4ccba625ba79a82f75e5658c0c2fa4336c0, the public key is 03d7b3bc2d0b4b72a845c469c9fee3c8cf475a2f237e379d7f75a4f463f7bd6ebd:

From this you can derive the address by first applying the HASH-160 (where HASH-160(x) = RIPEMD-160(SHA-256(x))), then adding network byte (prefix) and checksum (postfix), and finally converting the whole data into Base58 format. The detailed process of converting a public key to an address is described here: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
Though you probably have Bitcoin libraries doing the dirty work, the following small Python script converts the public key to the address:
 #!/usr/bin/env python
 from hashlib import *
 from base58 import *

def SHA256D(bstr):
    return sha256(sha256(bstr).digest()).digest()

def ConvertPKHToAddress(prefix, addr):
    data = prefix + addr
    return b58encode(data + SHA256D(data)[:4])

def PubkeyToAddress(pubkey_hex):
    pubkey = bytearray.fromhex(pubkey_hex)
    round1 = sha256(pubkey).digest()
    h = new('ripemd160')
    h.update(round1)
    pubkey_hash = h.digest()
    return ConvertPKHToAddress(b'\x00', pubkey_hash)

pubkey = "03d7b3bc2d0b4b72a845c469c9fee3c8cf475a2f237e379d7f75a4f463f7bd6ebd"
print("Address: %s" % PubkeyToAddress(pubkey))

This leads to the following expected result:
$ ./pubkey_to_script.py
Address: 1J16FUpZsS6My1FqHXpka5fztAnyFsBPf1

Thanks! I've confirmed it in PHP with Bitwasp library and posted the source code above. You are awesome!

I'm glad I could help! Note that this approach only works when the output of a P2PKH address is used as input. For P2SH addresses (that is, starting with '3...', mostly used for multisignature purposes) the sigScript can look quite different. Though very unlikely, there could be cases where you can't exactly tell from the scriptSig alone whether it was spent from a P2PKH or P2SH address and hence can't decide which prefix to use. Maybe this is the reason why in most answers people suggest to lookup the previous tx output.

Thank you for letting me know important things. I will consider about that. I think I will add checking whether P2PKH or P2SH before getting address. I guess most locking script nowadays are P2PKH. I will lookup bitcoind only non-P2PKH address so that I can reduce cost of access to bitcoind.

I translated this code from python to golang: https://gist.github.com/IvRRimum/2457e18092292e89eb7ee218c7dc70da


text:
Why is mempool deleted when restart bitcoind and how to keep it?
I'm using bitcoin core version 0.12.1 (To say precisely, I'm using addrindex patched bitcoin core by btcdrak)
I expected that mempool was maintained after restart bitcoind but that was deleted.
As far as I know that mempool is stored in chainstate/* directory as LevelDB data.
I read this article. What is the database for?
Can you describe this is why and how can I avoid it. Sometimes, I have to restart my bitcoind for some reasons (like system maintanance). In that time I want to maintain the mempool data.
Getting mempool data from peers..? takes a long time.
getmempoolinfo before bitcoind restart
$ curl --user 'xxx:yyy' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getmempoolinfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":{"size":15350,"bytes":120107104,"usage":258574880,"maxmempool":300000000,"mempoolminfee":0.00000000},"error":null,"id":"curltext"}

getmempoolinfo after bitcoind restart
$ curl --user 'xxx:yyy' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getmempoolinfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":{"size":0,"bytes":0,"usage":0,"maxmempool":300000000,"mempoolminfee":0.00000000},"error":null,"id":"curltext"}

So far, no released versions of Bitcoin Core exist that store the mempool on disk. That's why it's called the mempool; it's a pool of unconfirmed transactions kept in memory.
Version 0.14 is expected to introduce automatic dumping of the mempool to disk at shutdown.

"Version 0.14 is expected to introduce automatic dumping of the mempool to disk at shutdown." This was indeed done: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.14.0.md#retaining-the-mempool-across-restarts