Nytt hovedkort lover gull og grønne skoger

[efikkan]

Å investere i dedikerte miner-rigger for å tjene penger er en veldig dårlig idé, det er nemlig svært vanskelig å tjene inn igjen. For det er ikke bare topp-prisen til Bitcoin dere må ta i betraktning. For å regne ut profitt må dere ta salgspris, trekke fra provisjon til forhandler og eventuelle mellomledd. Det er ekstremt mye svindel, så noe svinn må medregnes. Deretter må inntekten beskattes, som blir trolig 28% hvis norske myndigheter anser det som en valuta (det kan være at myndighetene heller ser på transaksjonen fra utenlandsk valuta til NOK, og da blir det definitivt 28% skatt). Deretter må utstyrsprisen og eventuelt ekstra strømutgifter. Summen dere da sitter igjen med må så fordeles på antall arbeidstimer som har gått med. Jeg er spent på hvor god fortjeneste dere sitter igjen med.

 

Jeg ser derimot ingen ting i veien for å eksperimentere litt på maskinvare som eieren allerede har. En mer realistisk innstilling ville da vært å tenke at de kunne fått igjen litt av kjøpsprisen til maskinen, eventuelt lommerusk til å kjøpe et spill eller to.

 

Uansett må dere styre unna ASIC-svindlerne. Det har vært en rekke av "firma" som har dukket opp som skal selge fpga- og asic-løsninger til bitcoin-mining, og som krever solid betaling for produkter som tilsynelatende aldri kommer. Asicminer har bare forduftet, og avalon har bare vært lureri hele veien. Se på Butterfly labs, som er flinke til stadig å produsere ørten nye mockups uten at de klarer å levere varene. Bare ta en titt på brikkene de skal bruke.

Men la oss ta en liten matteutfordring:

* Bitcoin er dobbelhashet SHA-256, som betyr 2x64 runder = 128 runder per hash som skal regnes ut.

* For hvert forsøk brukes forrige hash pluss et generert tillegg, så kjøres altså 128 sykler på dette, og til slutt sjekkes det om det er x antall 0-er fremst i den nye summen.

 

Brikken som skal levere 4 GH/s har 16 som hver er på 250 MHz, dette gir 4 GH/s / 16 = 250 MH/s, dvs. 1 hel hash per klokke.

Data må overføres til og fra brikken for hver utregning. Bare resultatet fra hver utregning blir 256bit, og siden den skal regne ut 4 GH/s så må BGA144-bussen da minimum overføre på 8 GHz. I tillegg kommer overføringen av data til brikken som blir ennå mer.

Å generere 4 milliarder sett med tilfeldig data per sekund vil i seg selv kreve stor regnekraft.

 

Jeg har sagt det før, og jeg sier det igjen; hvis disse brikkene virkelig finnes så må de ha en brøkdel av oppgitt ytelse. Spesifikasjonene som er oppgitt er rett og slett umulig med dagens produksjonsteknikk.

 

For den som ikke har klart å legge sammen 2 + 2 ennå, disse maskinene er og blir S V I N D E L.

[PoTski]

Å investere i dedikerte miner-rigger for å tjene penger er en veldig dårlig idé, det er nemlig svært vanskelig å tjene inn igjen. For det er ikke bare topp-prisen til Bitcoin dere må ta i betraktning. For å regne ut profitt må dere ta salgspris, trekke fra provisjon til forhandler og eventuelle mellomledd. Det er ekstremt mye svindel, så noe svinn må medregnes. Deretter må inntekten beskattes, som blir trolig 28% hvis norske myndigheter anser det som en valuta (det kan være at myndighetene heller ser på transaksjonen fra utenlandsk valuta til NOK, og da blir det definitivt 28% skatt). Deretter må utstyrsprisen og eventuelt ekstra strømutgifter. Summen dere da sitter igjen med må så fordeles på antall arbeidstimer som har gått med. Jeg er spent på hvor god fortjeneste dere sitter igjen med.

 

Jeg ser derimot ingen ting i veien for å eksperimentere litt på maskinvare som eieren allerede har. En mer realistisk innstilling ville da vært å tenke at de kunne fått igjen litt av kjøpsprisen til maskinen, eventuelt lommerusk til å kjøpe et spill eller to.

 

Uansett må dere styre unna ASIC-svindlerne. Det har vært en rekke av "firma" som har dukket opp som skal selge fpga- og asic-løsninger til bitcoin-mining, og som krever solid betaling for produkter som tilsynelatende aldri kommer. Asicminer har bare forduftet, og avalon har bare vært lureri hele veien. Se på Butterfly labs, som er flinke til stadig å produsere ørten nye mockups uten at de klarer å levere varene. Bare ta en titt på brikkene de skal bruke.

Men la oss ta en liten matteutfordring:

* Bitcoin er dobbelhashet SHA-256, som betyr 2x64 runder = 128 runder per hash som skal regnes ut.

* For hvert forsøk brukes forrige hash pluss et generert tillegg, så kjøres altså 128 sykler på dette, og til slutt sjekkes det om det er x antall 0-er fremst i den nye summen.

 

Brikken som skal levere 4 GH/s har 16 som hver er på 250 MHz, dette gir 4 GH/s / 16 = 250 MH/s, dvs. 1 hel hash per klokke.

Data må overføres til og fra brikken for hver utregning. Bare resultatet fra hver utregning blir 256bit, og siden den skal regne ut 4 GH/s så må BGA144-bussen da minimum overføre på 8 GHz. I tillegg kommer overføringen av data til brikken som blir ennå mer.

Å generere 4 milliarder sett med tilfeldig data per sekund vil i seg selv kreve stor regnekraft.

 

Jeg har sagt det før, og jeg sier det igjen; hvis disse brikkene virkelig finnes så må de ha en brøkdel av oppgitt ytelse. Spesifikasjonene som er oppgitt er rett og slett umulig med dagens produksjonsteknikk.

 

For den som ikke har klart å legge sammen 2 + 2 ennå, disse maskinene er og blir S V I N D E L.

 

Tipper det er løst på denne måten.

 

http://lmgtfy.com/?q=HashFast+Open+Sources+Bitcoin+ASIC+Interface+Protocol

 

HashFast open sourcing their protocol has given insight into the operations driving their ASICs hashing. Cores are controlled through operations sent from a host?s CPU. HashFast provides each core with messages from the host CPU through an operation bus (the data link), which provide the cores with commands such as configuring clock speed (the OP_PLL_CONFIG operation), restarting the core (OP_RESET), and providing work information for hashing (OP_HASH).

hash_core

 

from page 14 of the Protocol Interface Guide

 

Hashing commands are among the most important aspects of chip design. In HashFast?s design, if an OP_HASH command is received while the core is currently hashing, it is stored in an input queue. This allows the core to have continuous work after finding an acceptable hash. Each OP_HASH operation also contains a unique sequence number used for retrieving relevant information about the hash later on.

 

When a hash is found that meets the difficulty requirement in the OP_HASH operation, the hash core returns back the nonce that was used, as well as the OP_HASH?s sequence number. The host can then look up the sequence number to find the block header information without having to constantly transmit it back and forth.