Markus W. schrieb: > 2024-04-21 12:27:30,268 - ERROR - Exception in RPC thread: script pubkey > of our address not found D.h. dass du nicht für dich selbst sondern für einen Pool minest, der dich dann "auszahlt". Deine Adresse kommt quasi in der Coinbase Transaktion nicht vor. In diesem Fall musst du "verify_solo" ausschalten.
@Mampf, ok und danke! Werde es so versuchen. PS.: ist Dein 0xaxe Repo schon soweit, dass man es Platinenmäßig einsetzen kann, oder gibt es noch nachträgliche Mods, die noch ausstehen?
:
Bearbeitet durch User
> PS.: ist Dein 0xaxe Repo schon soweit, dass man es Platinenmäßig > einsetzen kann, oder gibt es noch nachträgliche Mods, die noch > ausstehen? Der aktuelle Stand sollte problemlos funktionieren. Gerade wird noch gebastelt, um die teuren ADUM digital isolators durch günstigere OP Amps zu ersetzen, aber das ist schon eher "massieren". Kannst loslegen :) Werd im Repo dann noch Inbetriebnahme Tips einpflegen, beispielsweise kannst du auf dem 0xAxe ohne dicke 5V Power Supply die ASICs ohne Kühlung testen und verifizieren, ob die Chain geht, bevor du alles mit Kühlpaste vollschlonzt und einen Kühler draufschraubst. Ist viel Wert sowas zu haben / zu wissen! edit: würde empfehlen mit 1oz Innenlagen zu bestellen. Kann aber nicht sagen, ob das wirklich notwendig ist. Mein erster QAxe hatte 0,5oz und das hat genauso funktioniert. Der Strom durch die ASICs ist ja quasi der gleiche.
:
Bearbeitet durch User
@Mampf, kannst Du mir schreiben, wo in der FW/SW das Abbruchkriterium für die Temp. des Spannungsreglers von 70°C festgelegt ist. Ich würde diesen Wert gerne auf 75° festlegen, da mein Aufbau z.Z. meist um die 68°C hat und bei Spitzen die 70°-Grenze übersteigt, was zum Abbruch des Miners führt. Ist der Wert im Miner Python-Skript zu suchen, oder in Deiner FW? Bis ich den QAXE mit einem weiteren Lüfter über den Fet's kühlen kann wird es noch etwas dauern. Gehäuse ist noch in der Mache. Ich musste jetzt die Taktrate von 485MHz auf 400MHz runter setzen um über die Nacht zu kommen. LG+Danke Markus
Habe gerade von Rene ein Gehäuse gedruckt bekommen und den QAXE darin verbaut, siehe Anhang. Habe noch mit der Konfiguration vom solo.ckpool.org zu kämpfen. Bekomme die u.g. Fehler. Im public-pool.io läuft der QAXE ohne Probleme. Falls jemend was zur config.zml was sagen kann, dann bitte schön.
1 | debug_bm1366: false |
2 | verify_solo: false (auch mit true ausprobiert) |
3 | miner: qaxe |
4 | #suggest_difficulty: 2048 (gesetzt und auch auskommentiert - keine Abhilfe)
|
5 | #suggest_difficulty: 10000
|
6 | |
7 | qaxe: |
8 | name: QAxe |
9 | chips: 4 |
10 | fan_speed_1: 1.0 |
11 | fan_speed_2: 1.0 |
12 | asic_frequency: 450 |
13 | extranonce2_interval: 1.9 |
14 | serial_port_asic: "/dev/ttyACM0" |
15 | serial_port_ctrl: "/dev/ttyACM1" |
für die unterschiedlichen configs, bekomme ich die folgenden Fehler:
1 | btcmw@BTCMW:/dev/shm> grep ERR qaxe_20240423T142459.log |
2 | 2024-04-23 14:25:25,037 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991 |
3 | 2024-04-23 14:25:25,038 - ERROR - error flag set ... ending handle_incoming_rpc thread |
4 | 2024-04-23 14:25:29,834 - ERROR - send failed: [Errno 9] Bad file descriptor |
5 | 2024-04-23 14:25:30,391 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991 |
6 | 2024-04-23 14:25:30,391 - ERROR - error flag set ... ending handle_incoming_rpc thread |
7 | 2024-04-23 14:25:35,734 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991 |
8 | 2024-04-23 14:25:35,735 - ERROR - error flag set ... ending handle_incoming_rpc thread |
9 | 2024-04-23 14:25:41,078 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991 |
10 | 2024-04-23 14:25:41,078 - ERROR - error flag set ... ending handle_incoming_rpc thread |
11 | 2024-04-23 14:25:46,428 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522 |
12 | 2024-04-23 14:25:46,428 - ERROR - error flag set ... ending handle_incoming_rpc thread |
13 | 2024-04-23 14:25:51,764 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522 |
14 | 2024-04-23 14:25:51,764 - ERROR - error flag set ... ending handle_incoming_rpc thread |
15 | 2024-04-23 14:25:57,097 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522 |
16 | 2024-04-23 14:25:57,097 - ERROR - error flag set ... ending handle_incoming_rpc thread |
17 | 2024-04-23 14:26:02,428 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522 |
18 | 2024-04-23 14:26:02,429 - ERROR - error flag set ... ending handle_incoming_rpc thread |
oder
1 | btcmw@BTCMW:/dev/shm> grep ERR qaxe_20240423T142828.log |
2 | 2024-04-23 14:28:53,484 - ERROR - Exception in RPC thread: tcp connection closed ... |
3 | 2024-04-23 14:28:53,485 - ERROR - error flag set ... ending handle_incoming_rpc thread |
4 | 2024-04-23 14:28:58,718 - ERROR - Exception in RPC thread: tcp connection closed ... |
5 | 2024-04-23 14:28:58,718 - ERROR - error flag set ... ending handle_incoming_rpc thread |
6 | 2024-04-23 14:29:03,940 - ERROR - Exception in RPC thread: tcp connection closed ... |
7 | 2024-04-23 14:29:03,940 - ERROR - error flag set ... ending handle_incoming_rpc thread |
8 | 2024-04-23 14:29:09,168 - ERROR - Exception in RPC thread: tcp connection closed ... |
9 | 2024-04-23 14:29:09,168 - ERROR - error flag set ... ending handle_incoming_rpc thread |
10 | 2024-04-23 14:29:14,394 - ERROR - Exception in RPC thread: tcp connection closed ... |
11 | 2024-04-23 14:29:14,394 - ERROR - error flag set ... ending handle_incoming_rpc thread |
12 | 2024-04-23 14:29:19,618 - ERROR - Exception in RPC thread: tcp connection closed ... |
13 | 2024-04-23 14:29:19,618 - ERROR - error flag set ... ending handle_incoming_rpc thread |
14 | 2024-04-23 14:29:24,844 - ERROR - Exception in RPC thread: tcp connection closed ... |
15 | 2024-04-23 14:29:24,845 - ERROR - error flag set ... ending handle_incoming_rpc thread |
16 | 2024-04-23 14:29:30,074 - ERROR - Exception in RPC thread: tcp connection closed ... |
17 | 2024-04-23 14:29:30,074 - ERROR - error flag set ... ending handle_incoming_rpc thread |
18 | 2024-04-23 14:29:35,295 - ERROR - Exception in RPC thread: tcp connection closed ... |
19 | 2024-04-23 14:29:35,296 - ERROR - error flag set ... ending handle_incoming_rpc thread |
was bedeutet die u.g. Meldung?
1 | 2024-04-23 14:39:24,064 - INFO - cleaning jobs ... |
2 | 2024-04-23 14:39:24,064 - INFO - starting new job 64851638000eaaba |
3 | 2024-04-23 14:39:24,065 - ERROR - Exception in RPC thread: not getting all rewards! 572577967 vs 584263231 |
4 | 2024-04-23 14:39:24,065 - ERROR - error flag set ... ending handle_incoming_rpc thread |
Danke für sachdienliche Hinweise. Markus
Markus W. schrieb: > Ist der Wert im Miner Python-Skript zu suchen, oder in Deiner FW? Das ist an dieser Stelle: https://github.com/shufps/piaxe-miner/blob/master/piaxe/miner.py#L718 Sollte man vlt mal konfigurierbar machen 🤔 Markus W. schrieb: > Habe noch mit der Konfiguration vom solo.ckpool.org > zu kämpfen. Bekomme die u.g. Fehler. > Im public-pool.io läuft der QAXE ohne Probleme. Muss ich mal mit ckpool testen, hatte noch keine Zeit dafür.
@Mampf, danke habe ich nun angepasst.
1 | if temp["temp"][i] > 75.0: |
Markus
@Mampf zur Info >Hmm, vlt sollte ich das irgendwie anders machen, damit man durch die >0-Werte nicht verunsichert wird
1 | 2024-04-26 08:11:23,453 - INFO - temperature and voltage: {'temp': [28.375, 58.875, 0, 0]} |
2 | |
3 | |
4 | L#335 .../piaxe/miner.py |
5 | def read_temperature_and_voltage(self): |
6 | |
7 | return { |
8 | "temp": [status.temp1 * 0.0625, status.temp2 * 0.0625, 0, 0], |
9 | #"voltage": [0, 0, 0, 0], <== disable line 335 to disable voltage output
|
10 | }
|
LG Markus
Markus W. schrieb: > zur Info Das ist keine besonders saubere Lösung, weil man dann Hardware-Varianten hat, die unterschiedliche Results zurückliefern und es wird an ein paar Stellen davon ausgegangen, dass es immer ein Array mit 4 Elementen ist. In einem Arbeits-Branch hab ich die 0 Werte durch "None" ersetzt, ist evtl weniger verwirrend^^ Könnte ich mal in meinen Main Branch mergen, support für den BM1368 kommt dann quasi auch dazu.
@Mampf, sauber wollte ich es nicht sofort machen, sondern 'quick and dirty' Für mich passt es soweit. War ein Hüftschuß heute morgen. Wo die config.yml gelesen wird habe ich nicht im einzelnen eruiert. Sollte das Wochenende es hergeben, dann versuche ich mich daran. Du kannst es ja dann ins git übernehmen, sofern Dir mein Ansatz zusagt. LG Markus PS.: gibt es was Neues zum solo.ckpool.org?
:
Bearbeitet durch User
@Markus, ich bin noch da, hatte nur keine Zeit. Gehäuse sende ich hoffentlich Morgen raus. Zitat: was bedeutet die u.g. Meldung? 2024-04-23 14:39:24,064 - INFO - cleaning jobs ... 2024-04-23 14:39:24,064 - INFO - starting new job 64851638000eaaba 2024-04-23 14:39:24,065 - ERROR - Exception in RPC thread: not getting all rewards! 572577967 vs 584263231 2024-04-23 14:39:24,065 - ERROR - error flag set ... ending handle_incoming_rpc thread Danke für sachdienliche Hinweise. Zitat Ende Das kommt daher das wenn du auf dem solo.ckpool minest, der Reward geteilt wird. 2% gehen an den Pool, der Rest + Fees für dich. Du bist entweder im echten solo mode, oder der Code berücksichtigt das nicht das es zwei Output Adressen gibt. Die Adresse vom solo.ckpool ist bc1q28kkr5hk4gnqe3evma6runjrd2pvqyp8fpwfzu Die steht zuerst im script. Deine Adresse bekommt dann den Rest 98%. Du kannst dir das mal im btc explorer Ansehen: https://explorer.btc.com/de/btc/block/841286 Das war der Block der gestern im solo.ckpool gefunden wurde. Roland
:
Bearbeitet durch User
Hallo Roland, danke für den Hinweis zum solo.ckpool.org Im Miner gibt es nur einen Parameter für den user, der der öffentlichen btc Adr. entspricht. Ich bin noch nicht tief in der Materie drin um die btc api von pools zu verstehen. Hoffe bald diese Wissenslücke zu stopfen. Gerade nehme ich den zweiten Qaxe in Betrieb. Zickt noch etwas rum, aber ich hoffe es heute Abend noch hin zu bekommen. LG Markus
Hallo Mampf, ich krieg einen Vogel. Wollte den zweiten QAXE flashen (mit dem Binary, welches ich schon in den ersten QAXE übertragen hatte) Auch ein Neubau der FW hat nicht geholfen.
1 | 2024-04-29 22:21:48,612 - DEBUG - rx len: b'\x02' |
2 | 2024-04-29 22:21:48,612 - DEBUG - <- 0802 |
3 | 2024-04-29 22:21:54,113 - DEBUG - -> 55aa510900a49000ffff1c |
4 | 2024-04-29 22:21:54,114 - DEBUG - -> 55aa510900a49000ffff1c |
5 | 2024-04-29 22:21:54,115 - DEBUG - -> 55aa510900a49000ffff1c |
6 | 2024-04-29 22:21:54,115 - DEBUG - -> 55aa520500000a |
7 | 2024-04-29 22:21:55,117 - DEBUG - -> 55aa5305000003 |
8 | 2024-04-29 22:21:55,118 - ERROR - Uncaught exception |
9 | Traceback (most recent call last): |
10 | File "/dev/shm/qaxe-miner-mw-py-env/./pyminer.py", line 566, in <module> |
11 | qaxeMiner.init() |
12 | File "/dev/shm/qaxe-miner-mw-py-env/qaxe/miner.py", line 293, in init |
13 | chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled) |
14 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
15 | File "/dev/shm/qaxe-miner-mw-py-env/qaxe/bm1366.py", line 310, in init |
16 | return send_init(frequency, expected, chips_enabled) |
17 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
18 | File "/dev/shm/qaxe-miner-mw-py-env/qaxe/bm1366.py", line 257, in send_init |
19 | raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}") |
20 | Exception: chips mismatch. expected: 4, actual: 0 |
und schon wieder bekomme ich den selben Fehler, wie beim ersten mal.
1 | DEFMT_LOG=info cargo objcopy --release -- -O binary qaxe-fw-L151C8.bin |
2 | Compiling embassy-stm32l1-examples v0.1.0 (/dev/shm/qaxe/firmware/fw-L151C8) |
3 | Finished release [optimized + debuginfo] target(s) in 1.17s |
1 | >st-flash --connect-under-reset write /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin 0x8000000 |
2 | st-flash 1.8.0-13-g40ee5f4 |
3 | 2024-04-29T22:18:02 WARN common.c: NRST is not connected |
4 | 2024-04-29T22:18:02 INFO common.c: STM32L1xx_Cat_2: 32 KiB SRAM, 64 KiB flash in at least 256 byte pages. |
5 | file /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin md5 checksum: 75984add1d8269e8a991796ccf7c184, stlink checksum: 0x005a004d |
6 | 2024-04-29T22:18:02 INFO common_flash.c: Attempting to write 57264 (0xdfb0) bytes to stm32 address: 134217728 (0x8000000) |
7 | -> Flash page at 0x8000000 erased (size: 0x100) |
8 | -> Flash page at 0x8000100 erased (size: 0x100) |
9 | ...
|
10 | -> Flash page at 0x800de00 erased (size: 0x100) |
11 | -> Flash page at 0x800df00 erased (size: 0x100) |
12 | |
13 | 2024-04-29T22:18:03 INFO flash_loader.c: Starting Flash write for L0 |
14 | 2024-04-29T22:18:03 INFO flash_loader.c: Successfully loaded flash loader in sram |
15 | 2024-04-29T22:18:03 INFO flash_loader.c: Clear DFSR |
16 | 1/447 halfpages written |
17 | 2/447 halfpages written |
18 | ...
|
19 | 446/447 halfpages written |
20 | 447/447 halfpages written |
21 | |
22 | 2024-04-29T22:18:12 INFO common_flash.c: Starting verification of write complete |
23 | 2024-04-29T22:18:13 INFO common_flash.c: Flash written and verified! jolly good! |
Hast Du so was ähnliches bei anderen qaxe bemerkt? Im Anhang mein FW bin. Hast Du die Möglichkeit es mit Deiner FW zu vergleichen? Markus
Markus W. schrieb: > und schon wieder bekomme ich den selben Fehler, wie beim > ersten mal. Nö ist nicht der selbe Fehler, du bekommst garkeine Antwort von den ASICs. Bei deinem Problem zuvor war die Antwort "nur" verstümmelt. Die Firmaware passt sicherlich, das wurde richtig als .bin exportiert. Da musst du evtl nochmal ASICs nachlöten 🙈 Oder Sachen wie 1,8V und 0,8V checken, die Level-Shifter prüfen und sowas
:
Bearbeitet durch User
Ich werde am WE den dritten QAXE in Betrieb nehmen und mal schauen, ob dieser nach dem Flashen sofort anläuft. Wenn ja, dann weiß ich zumindest, dass ich an meiner Rust-Installation keinen Wurm habe. Ich habe nämlich zwischenzeitlich bei meinem Rolling OS Release einen Update gemacht, so daß ich nicht ausschließen kann, dass da nicht was faul ist. Der Miner bekommt in der ASIC-Prüfprocedure ein None zurück, soweit konnte ich den Fehler bereits eingrenzen. Auch habe ich diese Meldung in die Debug-Ausgabe eingebaut, damit man das im Log auch findet.
1 | def count_asic_chips(): |
2 | send_BM1366(TYPE_CMD | GROUP_ALL | CMD_READ, [0x00, 0x00]) |
3 | |
4 | chip_counter = 0 |
5 | while True: |
6 | data = serial_rx_func(11, 1000) |
7 | |
8 | if data is None: |
9 | logging.debug("Initializing BM1366 => count_asic_chips() serial_rx_func() returns None value!") |
10 | break
|
11 | |
12 | # only count chip id responses
|
13 | if "aa5513660000" not in binascii.hexlify(data).decode('utf8'): |
14 | continue
|
15 | |
16 | chip_counter += 1 |
17 | |
18 | send_BM1366(TYPE_CMD | GROUP_ALL | CMD_INACTIVE, [0x00, 0x00]) |
19 | |
20 | return chip_counter |
Melde mich am WE wieder. Markus PS.: serial_rx_func(11, 1000) ich nehme an die 1000 sind ein Timeout in ms?
:
Bearbeitet durch User
Markus W. schrieb: > PS.: serial_rx_func(11, 1000) ich nehme an die 1000 sind ein Timeout in > ms? Jap genau, wenn für 1s keine chip ID responses mehr kommen, nimmt man an, es kommen keine weiteren mehr.
Kleiner Statusupdate, nachdem ich heute QAXE#3 mit der FW in Betrieb nehmen konnte, weiß ich, dass meine RUST Entwicklerumgebung soweit ok ist. D.h. QAXE#2 hat noch ein Aufbauproblem. Jetzt muss ich die Platine sichten und nach Brücken oder anderen Fehlern durchsuchen. Die Spannungen passen soweit. AM Wochenende sehe ich mir die seriellen Signale zu den ASICs an, ob sie richtig durchgeschleift werden. Platine vier ist auch schon in Wartestellung, da fehlen mir nur noch die ASICs. Falls jemand welche günstig (d.h. <15€/St., BM1366 AL od. AG) abzugeben hat, dann bitte eine PM an mich. Markus
So num mit fertig verdrahtetem NT und bereit zum Minen. Markus
Zum ckpool, funktioniert bei mir einwandfrei 🤔 config_ckpool.yml:
1 | debug_bm1366: true |
2 | verify_solo: false |
3 | miner: qaxe |
4 | #suggest_difficulty: 2048 |
5 | |
6 | qaxe: |
7 | name: QAxe |
8 | chips: 4 |
9 | fan_speed_1: 1.0 |
10 | fan_speed_2: 1.0 |
11 | asic_frequency: 485 |
12 | extranonce2_interval: 1.9 |
13 | serial_port_asic: "/dev/ttyACM0" |
14 | serial_port_ctrl: "/dev/ttyACM1" |
15 | |
16 | ...usw... |
start_ckpool.sh:
1 | #!/bin/bash
|
2 | python3 ./pyminer.py -o stratum+tcp://solo.ckpool.org:3333 -P -u bc1xxx.worker3 -p x -l mainnet.log -d -c config_ckpool.yml |
Danke Thomas, werde Deine Einstellungen mal bei meinem QAXE#3 testen. Hast Du eine Bezugsquelle, bei der man die ASICs billig bekommt? LG Markus
Markus W. schrieb: > So num mit fertig verdrahtetem NT und bereit zum Minen. > > Markus Das gute Meanwell, kann ich nur Empfehlen, die Nutze ich nun über 20 Jahre und hatte keine Ausfälle.
Roland schrieb: > Das gute Meanwell, kann ich nur Empfehlen, die Nutze ich nun über 20 > Jahre und hatte keine Ausfälle. ob die heutigen das auch noch können?
Gibt wieder eine neue Variante - Standalone mit vier BM1368 @ 2.5TH avg bei 50W. Ist ein Derivat vom NerdAxe. Der NerdAxe ist ein BitAxe mit Nerdminer Display. Jetzt gibts einen NerdQAxe+ ... quasi ein QAxe+ mit Nerdminer-Display Upgrade. Hat auch noch einen deutlich besseren 1,2V Buck Konverter bekommen, der über 10°C kühler läuft. Happy building 🎉 https://github.com/shufps/qaxe/tree/main/nerdqaxe%2B edit: InfluxDB Integration gibts jetzt auch schon für AxeOs (die Firmware) edit2: ganz vielleicht bau ich noch einen NerdQaxe++ mit BM1370 ... Der hätte dann irgendsowas mit ähm 4TH bis 4.8TH @ 68W oder so ... Ganz genau weiß ich es nicht^^ Aber ich bin erstmal damit zufrieden^^
:
Bearbeitet durch User
Moin, Unnn - schonmal was erfolgreich geschuerft? Also so'n Hash-Nugget gefunden? scnr, WK
Dergute W. schrieb: > Unnn - schonmal was erfolgreich geschuerft? Also so'n Hash-Nugget > gefunden? Nope, aber ein BitAxe hat letztes Monat einen gefunden^^
Meiner war es leider nicht - habe aber auch davon gelesen - und nur mit 400GH Rechenleistung. Markus
Mampf F. schrieb: > Dergute W. schrieb: >> Unnn - schonmal was erfolgreich geschuerft? Also so'n Hash-Nugget >> gefunden? > > Nope, aber ein BitAxe hat letztes Monat einen gefunden^^ Letzen Monat gab es 8 Ziehungen bei Lotto, und jedesmal gabs mindestens 5-stellige Gewinne. Technisch sind so ein paar beschriftete Tischtennisbälle natürlich nicht so geil wie eine globale blockchain, aber was soll’s. Oliver
Wer die Wahrscheinlichkeit dieses Glückspieles abschätzen will, kann mal hier nachsehen: https://www.blocktrainer.de/tools-services/solo-mining-rechner Auf dieser Seite gibt es auch Infos zu Neuentwicklungen: https://www.blocktrainer.de/blog/bitaxe-neues-modell-und-revolutionaeres-zubehoer
Oliver S. schrieb: > Letzen Monat gab es 8 Ziehungen bei Lotto, und jedesmal gabs mindestens > 5-stellige Gewinne. Es gibt in Deutschland jährlich etwa 100 neue Lottomillionäre.
Nur das die Chance bei einem QAxe mit ca. 1.6TH/s bei 24h/7d im Jahr bei bei knapp 1:10000 liegt. Wie viele Lotto-Kästchen Du im Jahr ausfüllen müsstest um die gleich Chancen zu erzielen kannst Du Dir ja selbst ausrechnen, wenn auch ein Sechser mehr (meistens) Gewinn bringt. Markus PS.: zum Lotto-Glück: Siehe auch: https://matheerklaert.de/wahrscheinlichkeit-lotto-6-aus-49/ Noch zum Vergleich die letzten beiden Lotto Ziehungen.
1 | Treffer Wahrscheinlichkeit Gewinn Ziehung |
2 | ==========================================================================
|
3 | 5 Richtige + Superzahl 1 zu 542 008 6400 Euro (21.08.24) |
4 | 5 Richtige + Superzahl 1 zu 542 008 21077 Euro (17.08.24) |
5 | 6 Richtige 1 zu 15 537 573 256864 Euro (21.08.24) |
6 | 6 Richtige 1 zu 15 537 573 1185590 Euro (17.08.24) |
3.25BTC sind dagegen z.Z. knapp 240T$
:
Bearbeitet durch User
Markus W. schrieb: > im Jahr bei bei knapp 1:10000 liegt. Bei der 4-Chip 1368er Variante sagt ckpool sogar was von 1:4600, dass man im Jahr einen Block löst!
Mampf F. schrieb: > Bei der 4-Chip 1368er Variante sagt ckpool sogar was von 1:4600, dass > man im Jahr einen Block löst! Sudoku für ICs? Klingt stark nach ZEN . . .;-) https://de.wikipedia.org/wiki/Zen
Bin jetzt ein Jahr Member auf OSMU 🥳 (OSMU ist diese Open Source Miner United Discord Community, die open source und open hardware bitcoin miner entwickelt). Im Bild eine Kollektion was ich das Jahr über entwickelt habe ... War ich fleißig 🙈 Jetzt ist langsam ein Stand erreicht, wo ich mit dem ähm Stand-der-Technik aufgeholt hab und es keine neueren Chips mehr gibt 😂 Der Antminer S21 Pro hat den nagelneuen BM1370 Chip eingebaut - dafür hab ich den NerdQAxe++ entwickelt. Schafft 4,8T bei 85W 🤤 Also jetzt erstmal eine Entwicklungspause bis es wieder was neues gibt 😂 Anbei auch noch zwei Bildchen vom OCTAXE Gamma. Ein Freund hat mein Design geforkt und es von 4 auf 8 Chips skaliert. Mit 2,5% Overclocking erreicht er 10T Durchschnitt 🤯
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.