Merkle Tree hashing

I’m trying to implement my own Markle Tree, currently I’m working on getting the hashing done correctly.

I’ve used some hashes from

Example inputs (first two hashes from blockexplorer):

Ina: 3a459eab5f0cf8394a21e04d2ed3b2beeaa59795912e20b9c680e9db74dfb18c

Inb: be38f46f0eccba72416aed715851fd07b881ffb7928b7622847314588e06a6b7

Concatenated string (H1+H2): 3a459eab5f0cf8394a21e04d2ed3b2beeaa59795912e20b9c680e9db74dfb18cbe38f46f0eccba72416aed715851fd07b881ffb7928b7622847314588e06a6b7

Hash of concatenated string:
Ans v1: b5916d6bc34bd4157aa73c3d799a6cfcef85e0659465734362d0cebb8901e93d

Final hash of concatenated string:
Ans v2: 215f8397a3090a0bc8f4a2e98609a10d55fc7b939fa1ecf9803df20b1ee089a2

Result I got:

Expected result:

Checked my calculations “manually” using
and got the same results.

Am I doing someting wrong following this example: .
I take my input hashes, concatenate them together, and double SHA256 that string. I also tried treating the input strings as a and b, that is, first double SHA256 them, and only then join them together, but the result was also wrong. Does anyone have a step-by-step example of proper hashing of the Merkle Tree?

What happened with MtGox on 2011/9/12?

On that date, some erratic out-of-spread trades appeared on MtGox.

The explanation given says that accounts may have been compromised by the CosbyCoin attack on I do not understand how this can lead to out-of-spread orders being executed.

He says the issue is resolved and proceeds to give us a speech about password security and says that we should keep trading “in confidence”.

That does not satisfy me at all.

Can I buy/sell a lot of bitcoins without moving the price?

I am curious about how to acquire a lot of bitcoins (or similarly move a lot of bitcoins) without hitting the bid/ask

I don’t care about blockexplorer, I am just curious about price discovery

are there any darkpools? could I just use an illiquid exchange and personally contact the counterparty and have them take the trade

options would be good too, this would make acquiring bitcoins at a certain strike easier as this is already a negotiation between the person on the other side of the contract

Can I download the whole block chain from somewhere?

Every time I turn on the Bitcoin client it takes days to catch up with the block chain.

Are there alternatives to getting it trickling through the peer-to-peer network? Can I just download it somewhere? Wouldn’t this be ideal for distribution via BitTorrent?

If so, how do I import it into the Bitcoin client?

My client would still be validating this data (can it?), and it is all signed and proof-of-worked, so there is no real security problem here, is there?

How does change work in a bitcoin transaction?

It seems that when you send a bitcoin transaction, all the coins in the sending address are spent in that transaction, divided into the amount that you intended to send, and “change”, which goes back to you, but at another (newly created) receiving address.

That makes it a bit difficult to track your balance on block explorer (especially since the new receiving address does not seem to be displayed in the Bitcoin client anywhere).

Does it have it have to work like this, or is this a specific implementation detail of the client software?

Also, do you have to wait for change to be confirmed before you can spend it again?

No OpenCL platforms found?

Is it possible to mine with Nvidia Quadro 600? Both GUIMiner and DiabloMiner report that no OpenCL platforms/devices were found. How can I check if GPU has OpenCL?

Decentralized escrow functionality built into Bitcoin?

AFAIK there are a few websites out there that offer escrow services for Bitcoin. Those however are central, i.e. I have to “trust” them.

Is it being discussed, is it theoretically possible, or does the blockchain technology already enable to implement a decentralized escrow service?

After all, it is easy to imagine that an escrow holder could be nothing more than a “virtual” party or a “bot”, with its own wallet or private keys, that two negotiating parties could cast into existence. After the transaction has completed (or cancelled), the software would release (or revoke) the entrusted value to the respective party.

Update: If two parties cannot come to agreement, I can think of these solutions for now:

  1. There could be a form of escrow option that will be chosen where at least one party is public facing and reputational, e.g. a (online) shop, that will be trusted by the other party not to deceive.
  2. Two more “ordinarily” trading parties would choose an escrow option where the funds will never be released in the case of conflict at first. If they disclosed identity to each other, a court hearing could then be invoked which should usually come to a resolution, and the losing party will be enforced by law to provide value. Should Bitcoin never be accepted as negotiable matter by traditional jurisdiction, an alternative, equivalent infrastructure is thinkable, but let’s leave that to another question for now.
  3. This proposal by user Meni Rosenfeld:

    How about this. There is a box in which there are two types of coins,
    “deposit” and “payment”. Both parties have permission to open the box.
    When the box is opened, the deposits go to whoever put them, and the
    payment goes to the party other than the one who opened it.

    So first the buyer and seller both put a small deposit in the box.
    This is safe since they can get it back. Then the buyer puts the
    entire sum of the payment in the box. Now:

    1. If the seller sends the goods, the buyer will open the box and the
      seller will receive the funds. He is incentivized not to be lazy or
      spiteful because he wants his deposit back.
    2. If the seller for any reason wants to back out of the deal, he can
      open the box and have the payment return to the buyer, and is
      incentivized to do so because he wants his deposit back.
    3. If the seller goes with the “reimbursement” plot, the buyer knows
      he is scamming (since the seller should have just opened the box) and
      ignore the request. (There is a potential weakness in that the buyer
      can “defect” and open the box anyway, to get the deposit. This may be
      alleviated by having the buyer’s deposit smaller than the seller’s,
      giving him more bargaining power).
    4. A fraudulent seller is not incentivized to try this on N people
      until it succeeds, since every failure costs him his deposit. Hence,
      scenario 3 in which the money is burned should very rarely happen.

    In any case this isn’t supposed to be bullet-proof, just a significant
    extra protection for sellers who already pass the sniff-test.

    Additionally, the box can specify a charity address, agreed upon by
    both parties, to which the buyer has permission to send all funds,
    deposits and payment. So in the worst case the money will go to

    I’m not sure about the technical implementation details but all this
    should be very doable.