Maand: september 2011

How would I go about making the simplest form of a CPU bitcoin miner? I have not been able to find documentation on the whole process…

Why is 6 is the number of confirmations that is considered secure? I haven’t found any mathematical explanation or otherwise that explains why it is 6 and not 5 or 7. Is there a historical reason for 6? Is there a specific way to calculate it so 6 is just a number that was chosen?

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 http://blockexplorer.com/rawblock/000000000000a85d42610b292d2baebe54ff0c854847fe3d2ca37ac7d6e46b99

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:
215f8397a3090a0bc8f4a2e98609a10d55fc7b939fa1ecf9803df20b1ee089a2

Expected result:
13a3595f2610c8e4d727130daade66c772fdec4bd2463d773fd0f85c20ced32d

Checked my calculations “manually” using http://www.fileformat.info/tool/hash.htm?hex=b5916d6bc34bd4157aa73c3d799a6cfcef85e0659465734362d0cebb8901e93d
and got the same results.

Am I doing someting wrong following this example: https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees .
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?

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

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

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

That does not satisfy me at all.

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

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?

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?

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
   charity.

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

Bitcoin protocol supports scripts.

• How do they work?
• How are those implemented?
• What are their intended usages?
• When are they planned to be used?

One of the arguments made against Bitcoin’s design choices is that it wastes resources authenticating transactions. In particular, finding small hashes is completely useless for the world.

Are there approaches (or other crypto-currencies) that use proof-of-work by working on some useful difficult problem? There are plenty of projects like SETI@home or Folding@home that distribute difficult but potentially useful calculations among different users, is there a way to use such useful calculations for building a proof-of-work system in a crypto-currency, or is there a fundamental reason (economic or computational) that a proof-of-work must involve useless work?