Do you think about partnership with big mining pools?

I'm interested if someone has a comparision of Head GPU miner and other miners to make a decision.

The project team does not give any information about the investment round.

We just need to wait for information about IEO and prepare Bitcoin.

Is the first Istanbul event your Atronocom team organizes?

I wish you a successful event and I hope to get to it if I succeed

I have never been there, but judging by the photos this is a very beautiful place.

Maybe I will be able to attend the event, as I am very interested in the Atronocom project

it is necessary at least to write correctly. But of course they have an account and you can download the software from there.

Judging by the fact that the project participates in conferences around the world and regularly publishes reports on the development of Cocos-BCX, the team does not need any investment or additional developers.

Çırağan Palace Kempinski is situated on the European shores of the Bosphorus, in a very convenient location between the districts of Besiktas and Ortakoy.

Like a charm, cheers zeilap. I haz blockchain!!

Thanks Zeilap, I think I follow, I hadn't found that entry in the specification before, I'll try it out when I get a chance.

Thanks for your reply!

I haven't, but I don't know what I would be looking for. I know what is in the data, I just don't know how long those fields are in any given block. I don't think a client code would help me.

I could have a look at another parser, but the whole reason I decided to write my own was because I couldn't find a clear simple one, and up to now it's been quite straightforward.

Any more help is welcome!

So what's the auto-logout time on this forum?

i.e. how long am i actually going to have to spend staring at this forum?

Hi there!

Help me out with this if you can:

https://bitcointalk.org/index.php?topic=210188.0

Bump, help a man out!

So I'll try to say something vaguely interesting as part of my 5 just-for-the-sake-of-it posts.

Since I've been watching BTC it has seemed that in general the BTC price on other exchanges has seemed to follow mtgox pretty well, accounting for a sensible delay or discrepancy down to the difficulty in transferring funds between exchanges. This is usually ensured by arbitrage between exchanges, but is not perfect due to delays in money transfer etc.

Since the DHS announcement it has seemed to me that the BTC/USD price has been markedly lower on other exchanges than Mtgox. This must be because people don't think they would easily be able to remove funds from (or deposit to) mtgox at the moment or in the near future, or possibly also because people envisage mtgox's position as the most liquid exchange being threatened in the near future.

You might argue that the higher price on Mtgox highlights the benefits of bitcoin, people are willing to pay over the odds for it, in the knowledge that it will be easy to transfer their funds off very quickly, other currency might be much harder to remove.

In the medium term I wonder what this means for mtgox and BTC/USD. Mtgox is presumably going to lose a lot of US business, and there are other exchanges who are (at least somewhat) licensed in the US ready to pick up the slack. Also, once this business drains off mtgox over the coming months, will this upward pressure on the price be released, and lead to a little relaxation in the price? Pure speculation, who knows.

0 Mh/s

Me as well.

Shout out to all at the BTC conference!!

I'm writing a parser for the blockchain for my myself. I've been following the specs at

https://en.bitcoin.it/wiki/Genesis_block
https://en.bitcoin.it/wiki/Protocol_specification
and
https://en.bitcoin.it/wiki/Transactions

I've got to the point where I can follow the chain down to block #29664.

My problem is that I don't know how to infer the length of certain data entries, namely:

 - The number of transactions in a block
 - The number of inputs to a transaction
 - The number of outputs to a transaction
 - The length of the transaction input script
 - The length of the transaction output script

All of these entries are stated to be of length 1-9 bytes in the protocol specs.

But surely we need to have some way of predicting what length to read for these entries, in order to parse the chain successfully.

The (obviously flawed) assumption that they are always 1 byte long, fails at block #29664.

The only solution I can think of is trial and error until the block is parsed successfully (i.e. the magic bytes are correctly found at the start of the next block), but this seems really unsatisfactory.

Anyone know the solution to this problem?