Block in der Blockchain ohne Eingangstransaktionen?

[salventhor]

Hallo Community,

ich bin, was BTC betriff recht unbedarft, aber ich hab gestern folgendes gesehen:

Block # 350096, 1 Transaktion, 25 BTC neu generiert, größe 0,25 kb.

genau zu dieser Zeit ist lt. Blockchain.info die Zahl der Nodes eingebrochen auf knapp 650 Nodes.

kann mit vielleicht jemand erklären, wie einer einen Block gemined hat, der KEINE eingangstransaktionen beinhaltet?
ich denk, das geht nicht? 

Danke schonmal im voraus für Erklärungen!

[1715233713]

1715233713

[1715233713]

1715233713

[mezzomix]

Doch. Ein zentraler Bestandteil des System ist, dass jeder Miner selbst bestimmt, welche Transaktionen in "seinen" Block aufgenommen werden. Keine Transaktion ist dabei völlig legal. Machen das viele Miner, entwerten sie damit aber gleichzeitig ihre BTC und ihren Mining-Aufwand.

[fronti]

Es kann sogar ein Block erzeugt werden, der keinen Blockreward hat, also eigentlich komplett leer ist.
Nur ich glaub das will keiner machen 

[salventhor]

Danke für eure Infos.

Das bedeutet doch aber, das ich einen Block erschaffen könnte, den ich mit genau einer Transaktion selbst fülle, diesen dann löse und die 25 BTC kassiere, oder?

Also quasi 1 überweisung selbst durchführe, diese dann in einen Block aufnehme, den Durchrechnen lasse und damit dann einen Block gelöst hab, der mir 25 BTC bringen würde...

[asodinis]

Danke für eure Infos.

Das bedeutet doch aber, das ich einen Block erschaffen könnte, den ich mit genau einer Transaktion selbst fülle, diesen dann löse und die 25 BTC kassiere, oder?

Also quasi 1 überweisung selbst durchführe, diese dann in einen Block aufnehme, den Durchrechnen lasse und damit dann einen Block gelöst hab, der mir 25 BTC bringen würde...

Ja, die Miner können selbst entscheiden welche Transaktionen in den Block aufgenommen werden. Also könnte man auch nur eine einzelne eigene Transaktion übernehmen. Streng genommen ist das ja mit dem fraglichen Block passiert. Es existiert eine Transaktion über 25 BTC ohne Eingänge an einen Ausgang: Der Blockreward.

Leere Blöcke werden übrigens erzeugt um die Verbreitungsgeschwindigkeit zu erhöhen. Ein leerer Block verbreitet sich halt schneller, als einer mit 500KB Transaktionen. Das verschafft einem einen Vorteil, wenn zwei Parteien praktisch gleichzeitig einen Block finden. Im Gegenzug lässt man sich dadurch natürlich die Fees entgehen.

[lassdas]

Das bedeutet doch aber, das ich einen Block erschaffen könnte, den ich mit genau einer Transaktion selbst fülle, diesen dann löse und die 25 BTC kassiere, oder?

Also quasi 1 überweisung selbst durchführe, diese dann in einen Block aufnehme, den Durchrechnen lasse und damit dann einen Block gelöst hab, der mir 25 BTC bringen würde...

Das ist korrekt,
nur ändert das ja nichts daran, daß Du, um diesen Block zu erstellen, erstmal den entsprechenden Hash finden musst, dessen Difficulty hoch genug ist und der es Dir somit erst erlaubt, einen solchen Block zu erstellen.

Es wird ja nicht leichter einen Block zu finden, wenn er nur wenige (oder garkeine) Transaktionen enthält
und umgekehrt wirds auch nicht schwerer, wenn er viele Transaktionen enthält, die Difficulty ändert sich dadurch nicht.

[Sukrim]

Keine Transaktion ist dabei völlig legal.

Es kann sogar ein Block erzeugt werden, der keinen Blockreward hat, also eigentlich komplett leer ist.
Nur ich glaub das will keiner machen 

Man wird trotzdem eine Coinbase-Transaktion brauchen, auch wenn die keine Bitcoins beinhält, soweit ich das System verstehe.

[shorena]

Keine Transaktion ist dabei völlig legal.

Es kann sogar ein Block erzeugt werden, der keinen Blockreward hat, also eigentlich komplett leer ist.
Nur ich glaub das will keiner machen 

Man wird trotzdem eine Coinbase-Transaktion brauchen, auch wenn die keine Bitcoins beinhält, soweit ich das System verstehe.

Das ist zwar richtig, aber die 25 BTC muss man nicht einfordern, das ist optional. Ist wohl in der Verganenheit auch schon passiert, hab dafür aber keine Blocknummer im Kopf. Der code sagt aber deutlich bis zu 25 BTC reward. Jedenfalls zur Zeit. Es ist also eine coinbase TX denkbar die 0 satoshi "erzeugt".

Das bedeutet doch aber, das ich einen Block erschaffen könnte, den ich mit genau einer Transaktion selbst fülle, diesen dann löse und die 25 BTC kassiere, oder?

Also quasi 1 überweisung selbst durchführe, diese dann in einen Block aufnehme, den Durchrechnen lasse und damit dann einen Block gelöst hab, der mir 25 BTC bringen würde...

Das ist korrekt,
nur ändert das ja nichts daran, daß Du, um diesen Block zu erstellen, erstmal den entsprechenden Hash finden musst, dessen Difficulty hoch genug ist und der es Dir somit erst erlaubt, einen solchen Block zu erstellen.

Es wird ja nicht leichter einen Block zu finden, wenn er nur wenige (oder garkeine) Transaktionen enthält
und umgekehrt wirds auch nicht schwerer, wenn er viele Transaktionen enthält, die Difficulty ändert sich dadurch nicht.

Hmm, naja. Jede Transaktion im Block ändert die merkle root und hat damit auch Einfluss auf den Hahswert. Es kann also durchaus von Nachteil sein keine Transaktion einzufügen. Wenn man aber betrachtet was alles in einem Block manipuliert werden kann um einen anderen Hashwert zu erhalten, spielt das wohl eher eine untergeordnete Rolle.

[SebastianJu]

Hm... ich denke es wird ziemlich sinnlos sein einen leeren Block zu erzeugen. Erstens dauert es eh sehr lange bis einer gefunden ist, weshalb der Vorteil in der Übertragungsgeschwindigkeit minimal sein wird und zweitens wird es eher darauf ankommen zu wie vielen Nodes man verbunden ist. Hat man 51% der Nodes davon überzeugt dass man selbst den Block zuerst gefunden hat dann gewinn mant. Also würde ich eher versuchen möglichst alle Nodes, die ich irgendwie erreichen kann, mit meinem Block zu versorgen.

Jetzt habe ich mir die Blockgrößen angeschaut.

Der leere Block hat nur 0.25KB, keine MB, nicht mal ein KB. https://blockchain.info/de/block-height/350096

Einer der letzten normalen Blöcke hat 63KB: https://blockchain.info/de/block-height/360424

Ganz ehrlich... 63KB ist nichts. Das kann man superschnell propagieren. Wenn man gleichzeitig zu tausend nodes senden will dann muss man eben die entsprechende Bandbreite haben oder selbst noch ein paar Server die beim propagieren helfen. Genauso wenn die Nodes nur zu einigen verbinden. Mit mehreren eigenen Nodes würde man zu mehr anderen Nodes verbinden können und sich damit einen Vorteil verschaffen.

Ich dachte erst das könnte ein Problem sein aber irgendwie sehe ich nicht dass das ein Erfolgsmodell ist.

Ich könnte mir allerdings vorstellen dass es das irgendwann mal wird. Wenn es keine KB, sondern MB sind. Dann könnte es wirklich sehr lange dauern bis der Block von einem zum nächsten Node verbreitet wird. Ein leerer Block, der ein paar Sekunden danach gefunden wird, könnte bedeuten dass er sehr viel schneller verbreitet wird und damit "gewinnt".

Und wir reden über 20MB Blöcke.  Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.

[Chefin]

Naja..spätestens wenn er seine Bitcoin zu geld machen will muss er transferieren und das liegt dann im eigenen Interesse das im Block mehrere Transaktionen drin sind. Und genauso müssen seine Käufer wiederum ihre Bitcoins bekommen. Man wird ja nicht immer gleich jemanden finden der alle 25 btc auf einen Schlag kauft, eher ist es so, das die Coins krümelweise in den Umlauf gehen. Also weis man nie so genau, wann die eigenen Coins dran sind beim VK. Und man muss an den Börsen ebenfalls die vorherigen (billigeren) Angebote durchlassen, bevor jemand die Coins kauft.

Das halte ich für eine "natürliche" Regelfunktion.

[shorena]

-snip-
Und wir reden über 20MB Blöcke.  Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.

*pingel* 20MB beruhen auf einem Rechenfehler, konkret geht es um 4 bzw. 8 MB.

[qwk]

Es kann sogar ein Block erzeugt werden, der keinen Blockreward hat, also eigentlich komplett leer ist.
Nur ich glaub das will keiner machen 

Ist doch das Statussymbol schlechthin

[SebastianJu]

Naja..spätestens wenn er seine Bitcoin zu geld machen will muss er transferieren und das liegt dann im eigenen Interesse das im Block mehrere Transaktionen drin sind. Und genauso müssen seine Käufer wiederum ihre Bitcoins bekommen. Man wird ja nicht immer gleich jemanden finden der alle 25 btc auf einen Schlag kauft, eher ist es so, das die Coins krümelweise in den Umlauf gehen. Also weis man nie so genau, wann die eigenen Coins dran sind beim VK. Und man muss an den Börsen ebenfalls die vorherigen (billigeren) Angebote durchlassen, bevor jemand die Coins kauft.

Das halte ich für eine "natürliche" Regelfunktion.

Ich denke, wenn der Miner das wegen der Geschwindigkeit macht, dann wird er auch seinen Code nicht ändern um mal seine eigenen Transaktionen rein zu lassen. Er kann auch einfach warten bis irgendein anderer Miner seine Transaktion in einen Block packt. Er wird ja eh nur ab und zu einen Block finden. Er würde vielleicht drüber nachdenken wenn er 25% der Blöcke findet. Aber sonst hat er keinen echten Anreiz dazu.

Ich denke einfach, wenn man sich ein Netz von derzeit >40T Nodes vorstellt und jeder Node ist nur zu ein paar anderen Nodes verbunden, dann macht es einen riesigen Unterschied wie schnell >50% der Nodes den Block akzeptiert haben. Weil jeder Node den Block erst weiterschicken wird wenn er komplett geladen und geprüft wurde.

Mal sehen ob das künftig ein Problem wird. Wäre fraglich wie man das lösen könnte.

-snip-
Und wir reden über 20MB Blöcke.  Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.

*pingel* 20MB beruhen auf einem Rechenfehler, konkret geht es um 4 bzw. 8 MB.

Echt? Gilt das beim aktuellen 1MB auch?

[shorena]

-snip-
Mal sehen ob das künftig ein Problem wird. Wäre fraglich wie man das lösen könnte.

Es gibt da schon Ideen. Z.B. durch bloom filter[1], grob gesagt ist die Idee das die meisten Nodes die TX in den Blöcken eh schon kennen. Da reicht es dann zu verbreiten welche TX im Block sind und der vollständige Block muss nur noch in Ausnahmefällen übertragen werden, z.B. wenn ein Node hinterher hängt oder gerade erst online gekommen ist. Dadurch lassen sich Blöcke in fester Zeit (O(1)), also unabhängig von der Blockgröße, übertragen.

-snip-
Und wir reden über 20MB Blöcke.   Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.

*pingel* 20MB beruhen auf einem Rechenfehler, konkret geht es um 4 bzw. 8 MB.

Echt? Gilt das beim aktuellen 1MB auch?

Ne, das 1MB limit ist schon so im code. Softlimit ist zur Zeit 750KByte um das zu ändern muss man halt mal in die config Datei. Blöcke über 1 MB werden nicht akzeptiert. Gavin hat nur bei seinen Berechnungen einen Fehler gemacht und kam daher fälschlicher weise auf 20MB, es müssten aber eher 4 oder 8MB sein.


[1] https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

[SebastianJu]

-snip-
Mal sehen ob das künftig ein Problem wird. Wäre fraglich wie man das lösen könnte.

Es gibt da schon Ideen. Z.B. durch bloom filter[1], grob gesagt ist die Idee das die meisten Nodes die TX in den Blöcken eh schon kennen. Da reicht es dann zu verbreiten welche TX im Block sind und der vollständige Block muss nur noch in Ausnahmefällen übertragen werden, z.B. wenn ein Node hinterher hängt oder gerade erst online gekommen ist. Dadurch lassen sich Blöcke in fester Zeit (O(1)), also unabhängig von der Blockgröße, übertragen.

-snip-
Und wir reden über 20MB Blöcke.   Na ich frage mich ob das nicht ein Hindernis für die Verbreitung von Bitcoins werden könnte.

*pingel* 20MB beruhen auf einem Rechenfehler, konkret geht es um 4 bzw. 8 MB.

Echt? Gilt das beim aktuellen 1MB auch?

Ne, das 1MB limit ist schon so im code. Softlimit ist zur Zeit 750KByte um das zu ändern muss man halt mal in die config Datei. Blöcke über 1 MB werden nicht akzeptiert. Gavin hat nur bei seinen Berechnungen einen Fehler gemacht und kam daher fälschlicher weise auf 20MB, es müssten aber eher 4 oder 8MB sein.


[1] https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

*lach* Das ist aber peinlich wenn der Chefcoder einen solchen Fehler macht und gleichzeit laut "Feuer" ruft. 

bloom_filter klingt interessant. Gut dass da schon eine Lösung in Planung ist. Auch wenn ich mir das irgendwie schwer machbar vorstelle da der Server doch wissen muss welche Transaktionen letztendlich im Block gelandet sind bevor er prüfen kann ob ein Block, der ihm geschickt wurde, auch valide ist.

Aber so genau habe ich mich jetzt nicht mit der Technik beschäftigt. Kann sein dass ich das falsch sehe.