Der Prozess ist fließend, es wird ein Block gebaut, gerechnet, nachgeschaut ob man Transaktionen weiter hinzufügen kann und erneut gerechnet usw.
Die Einstellungen in der bitcoin.conf bestimmen ab welcher TX-Fee die TX in den Block Aufgenommen wird.
Zur Info: https://jlopp.github.io/bitcoin-core-config-generator/
Topic: Frage zum candidate block beim Mining (Read 121 times)
Hallo Freunde des Schürfens,
ich habe ein Verständnisproblem und hoffe hilfreiche Antworten zu bekommen. Und zwar:
wenn ein neuer Block gefunden und bestätigt wurde, so macht sich jede Full-Node an die Arbeit den nächsten Block zu basteln, um einen validen Hash zu generieren. Mir ist bekannt, dass die Full-Node anhand der Konfiguration die vom Nodebetreiber festgelegt wurde entscheidet, ob und welche Transaktionen aus dem Mempool herangezogen werden bei Bildung des candidate block. Viele Nodes picken sich verständlicherweise gerne diejenigen raus, die mit mehr Gebühren bezahlt wurden aber ums cherry-picking solls hier nicht gehen. Soweit ich richtig verstanden habe so muss der Block header zwei mal durch sha256 gejagt werden mit der Hoffnung einen Hash zu generieren der unterhalb dem aktuellen target liegt.
Der block header besteht aus folgenden Komponenten:
- Version
- Block Hash des vorherigen Blocks
- Merkle Root
- Zeitstempel
- Bits (vereinfachte Version des targets)
- Nonce
wenn jetzt meine Full-Node sich alle paar Sekunden aus dem Mempool (=Warteraum für zu verarbeitende Transaktionen) eine Transaktion zieht und somit den candidate block 'füllt' dann verändern sich doch dabei jedes Mal
- Merkle Root
- Zeitstempel
oder nicht? Wie soll die Full-Node dann anfangen zu rechnen, um nach der goldenen Nonce zu suchen? Wo liegt mein Denkfehler? Oder sieht das in der Praxis wie folgt aus:
Die Full-Node zieht sich auf einen Schlag sagen wir beispielsweise 800 Transakationen aus dem Mempool und generiert dabei den Merkle Root und einen fixen Zeitstempel. Und dann fängt erst die Suche nach der goldenen Nonce an ?
Grüße
citb0in
ich habe ein Verständnisproblem und hoffe hilfreiche Antworten zu bekommen. Und zwar:
wenn ein neuer Block gefunden und bestätigt wurde, so macht sich jede Full-Node an die Arbeit den nächsten Block zu basteln, um einen validen Hash zu generieren. Mir ist bekannt, dass die Full-Node anhand der Konfiguration die vom Nodebetreiber festgelegt wurde entscheidet, ob und welche Transaktionen aus dem Mempool herangezogen werden bei Bildung des candidate block. Viele Nodes picken sich verständlicherweise gerne diejenigen raus, die mit mehr Gebühren bezahlt wurden aber ums cherry-picking solls hier nicht gehen. Soweit ich richtig verstanden habe so muss der Block header zwei mal durch sha256 gejagt werden mit der Hoffnung einen Hash zu generieren der unterhalb dem aktuellen target liegt.
Der block header besteht aus folgenden Komponenten:
- Version
- Block Hash des vorherigen Blocks
- Merkle Root
- Zeitstempel
- Bits (vereinfachte Version des targets)
- Nonce
wenn jetzt meine Full-Node sich alle paar Sekunden aus dem Mempool (=Warteraum für zu verarbeitende Transaktionen) eine Transaktion zieht und somit den candidate block 'füllt' dann verändern sich doch dabei jedes Mal
- Merkle Root
- Zeitstempel
oder nicht? Wie soll die Full-Node dann anfangen zu rechnen, um nach der goldenen Nonce zu suchen? Wo liegt mein Denkfehler? Oder sieht das in der Praxis wie folgt aus:
Die Full-Node zieht sich auf einen Schlag sagen wir beispielsweise 800 Transakationen aus dem Mempool und generiert dabei den Merkle Root und einen fixen Zeitstempel. Und dann fängt erst die Suche nach der goldenen Nonce an ?
Grüße
citb0in
Jump to: