Huhu alle zusammen.
Moin
Ich wollte mich heute mal ein bisschen über Bitcoins schlau machen - nach 3 Stunden qualmt mir der Kopf und ich hab’s immer noch nicht begriffen!
Ich wäre froh, wenn ihr mir im Text markierte Aussagen [
¿¿¿] bestätigen oder widerlegen würdet.
Das sind von mir gemachte Schlussfolgerungen, bei denen ich gerne wissen würde ob diese zutreffend sind oder nicht.
Ich versuch das einfach mal so gut ich kann, ohne viele der Antworten hier gelesen zu haben. Nur soviel, es gibt viele Erklärungen die Metaphern benutzen und dadurch ungenau werden. Man bekommt dadurch zwar ein grobes Gefühl wie es geht, hat aber eigentlich doch nichts verstanden.
-snip-
Wenn ich das recht verstanden habe entspricht 1 Satoshis 1 nonce ¿¿¿ aber dazu kommen wir ja später noch…
Nein, nonce ist englisch und steht für '
Number used
once'. Die nonce ist fürs Mining wichtig und hat nichts mit Bitcoin Einheiten zu tun.
- Transparenz/Server/Pools:
Nachdem ich das ganze mal schnell getestet, ein paar Satoshis generiert habe und nun ein reicher Mann bin, kamen weitere Fragen auf.
Google brachte bis jetzt nicht die gewünschten Ergebnisse.
Ich glaube nicht das du mal eben ein paar Satoshis 'generiert' hast.
-snip-
1. Die mysteriöse Transaktion und das noch mysteriöse Konto dahinter
#1 Es gibt keine Konten.
„Es gibt keine Bitcoins, nur die Aufzeichnungen über Bitcoin-Transaktionen“
Ok soweit angekommen. Jetzt würde ich gerne konkrete Beispiele haben wie der Prozess auszusehen hat.
Was braucht man um mit Bitcoins zu arbeiten? Ein Konto. Ein Konto ist ja nichts anderes als ein geschützter Bereich auf den nur der/die Besitzer Zugriff haben.
Nein, ein Konto ist nicht das selbe wie ein verschlüsseltes Bild für das nur ich das Password kenne oder? Ich nehme mal an mit 'arbeiten' ist ausgeben gemeint. Bitcoin basiert auf dem Signatur Algorithmus ECDSA. Dieser funktioniert asymmetrisch. Es gibt also einen öffentlichen (zum verifizieren) und einen privaten Schlüssel (zum signieren).
Und da blick ich überhaupt nicht durch. Ausgangspunkt ist ja die sogenannte „Bitcoin-Adresse“.
In meinem Fall z.B.: „1DRed1fS1X1um4eVemLjdYZrNYkZ9CJqDg“. 1 für Einzelkonto 3 für irgendwas anderes (mehrere Besitzer). ¿¿¿
Nein. Bitcoin Adressen werden aus dem öffentlichen Schlüssel gebildet (Hashes SHA 256 und RIPEMD 160 und ein bisschen Prüfsumme und Prefix dazu). Weiter gibt es eine Script Sprache die klärt unter welchen Bedinungen Bitcoin ausgegeben werden können.
->
https://en.bitcoin.it/wiki/ScriptDer Prefix 1 an einer Adresse bedeutet das die Bitcoin die über diese Adresse empfangen werden nach bestimmten Regeln ausgegeben werden können. Diese Regeln heißen 'Version 1 Bitcoin Address' oder üblicher 'pay-to-pubkey-hash' und bestimmen eigentlich nur ein ganz bestimmtes Script.
Dieses Script lautet:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Es prüft mit dem öffentlichen Schlüssel zu dieser Adresse ob ein korrekte Signatur geleistet wurde. Der öffentliche Schlüssel wird vom Absender zur Verfügung gestellt und kann nicht ohne weiteres aus der Adresse abgeleitet werden. Wenn er erstmal bekannt ist, kann aber leicht geprüft werden um welche Adresse es geht.
Wie was wo in der Adresse definiert, dass ich der Besitzer bin und gewährleistet, dass nur ich Zugriff auf den „Betrag“ der Transaktion habe?
Gar nicht. Jeder(!) der über den (oder genau genommen die) privaten Schlüssel verfügt ist 'Besitzer'. Aufgrund der Verwendung von RIPEMD 160 (160 Bit) wird davon ausgegangen das zu jeder Adresse 2
96 gültige private Schlüssel existieren. 2
256-2
160Da sollte es doch ein Gegenstück geben, einen Hash oder was auch immer den nur ich kenne und der das „von – nach“ definiert…?
Die von nach Beziehung ist (noch mal in kurz): privater Schlüssel -> öffentlicher Schlüssel -> Adresse. Keiner der Wege ist nach aktuellem Stand der Technik umkehrbar (<-/->).
Also wenn ich jetzt mit irgendeiner Programmiersprache ein „Konto“ mit einer Passphrase erstellen möchte wie müsste das aussehen?
Lad die Bibliothek für Krypto und erzeug dir eine Zufallszahl zwischen 0x0 und 0x FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141. Das ist dein privater Schlüssel. Vermutlich bietet die Bib dann auch Funktionen um den Pubkey abzuleiten und Hashes zu bilden.
->
https://en.bitcoin.it/wiki/Secp256k1->
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addressesWelche Daten/Variablen bräuchte man zu sichern um den Prozess zu reproduzieren?
Wie kann es möglich sein das auch Offline zu machen ohne die Daten über einen Server zu verifizieren?
In meinem Kopf sieht das im Moment etwa so aus:
- Generierung der Passphrase bzw. Public-Private Key (wie hat das auszusehen) ¿¿¿
- Verschlüsselung der Passphrase ¿¿¿
- Generierung einer Bitcoin-Adresse ¿¿¿
- Wie wird der Besitzer definiert ¿¿¿
- Wie wird die Bitcoin-Adresse generiert ¿¿¿
Das sollte nun aus dem oben klar sein, sonst fragen.
- Wie werden die Daten beim Server registriert ¿¿¿
Gar nicht. Es wird spekuliert das der Zahlenraum groß genug und der verwendete Zufallszahlengenerator zufällig genug ist das keine Kollision vorkommt.
2. Die mysteriöse Verifizierung der Transaktion durch die Miner
Das Szenario wäre ja dann:
- Ich schicke jemandem die „Bitcoin-Adresse“
- Der andere überweist 1 Bitcoin an mich
- Die Transaktion wird auf einen der mysteriösen Server geladen ¿¿¿
- Die Miner laden die Transaktion herunter und beginnen mit der Verifizierung (6 = totales ok) und senden mysteriöse Daten and den mysteriösen Server ¿¿¿
- Mein Client sucht nach der Verifizierung und bestätigt den „erhalt“ ¿¿¿
Wie würde dann dieser Ablauf programmiertechnisch aussehen? Also nicht über einen Pool sondern direkt.
Ich gehe hier von (unpruned) Full Nodes aus und nicht von light wallets (wie z.B. electrum) die ggf. (in)direkt mit einem Full Node Kontakt aufnehmen. Ein Full Node ist ein Knoten im Netzwerk der alle bisherigen Blöcke gespeichert hat und somit die vollständige Historie aller Bitcoin Transaktionen kennt. Eine Transaktion sieht in etwa so aus:
{
"txid": "edc9545bb0dab665c35c3f42949ca3c4451d59dff24d88456f24dda7107fe89c",
"hash": "edc9545bb0dab665c35c3f42949ca3c4451d59dff24d88456f24dda7107fe89c",
"size": 1086,
"vsize": 1086,
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "28939417d65cba570d53968e63764c17b12e1410ee535f86c8d0b25a99f4d06b",
"vout": 0,
"scriptSig": {
"asm": "304502210094dccee98f54c5e76db9f4d4c2e6de8424ceb409853b84f5b5c6754105de56b4022075321ba46cf8ab0532a939f84a42feeffa80f52b70ca675be2be92717f4cedd8[ALL] 04e369909ed1e40bb67f45b0528126a35cdca949adf8ee607836400dbe96680e536df3713268213d409ec0fde242c5d7f7bf717a725d9b91857a3e258228a30f5c",
"hex": "48304502210094dccee98f54c5e76db9f4d4c2e6de8424ceb409853b84f5b5c6754105de56b4022075321ba46cf8ab0532a939f84a42feeffa80f52b70ca675be2be92717f4cedd8014104e369909ed1e40bb67f45b0528126a35cdca949adf8ee607836400dbe96680e536df3713268213d409ec0fde242c5d7f7bf717a725d9b91857a3e258228a30f5c"
},
"sequence": 4294967293
},
{
"txid": "8cdff588f2557e7172c2fcf75754f05a4c5656403e03ab2c98aeeb5b66bdaec0",
"vout": 0,
"scriptSig": {
"asm": "304402204e6ac5a770ac61f5def2031c457fc883b58840af5ba409663584d7cd06d7ebdb022059fb6734410bc732876afc29f6432b8e265e4eb74140407ba11cf683257fc451[ALL] 0413ff5dbebb3086836c04e16b3b50d29eac98b1c37bf3d8da0c1b1238650eeed1d633ef9f617c808f332c1d722dad8e1972e0f2faccb935499fe7e951e2857cc6",
"hex": "47304402204e6ac5a770ac61f5def2031c457fc883b58840af5ba409663584d7cd06d7ebdb022059fb6734410bc732876afc29f6432b8e265e4eb74140407ba11cf683257fc45101410413ff5dbebb3086836c04e16b3b50d29eac98b1c37bf3d8da0c1b1238650eeed1d633ef9f617c808f332c1d722dad8e1972e0f2faccb935499fe7e951e2857cc6"
},
"sequence": 4294967293
},
{
"txid": "a316baedc374484a766c10b052d261d410cfa299b347caa2403ad9da7da65bd6",
"vout": 18,
"scriptSig": {
"asm": "304402201de00add2e25b64fb59a1b586478d1a561ddd40fa9265994025852d93e86c5dd02207c31dca9142105eddcc17c311cb0f48f28c8adcad27b6ae3d97d8dc05cfe0ec0[ALL] 04b88c0ef1ec6f52fdf09e34e10ccec08076b23c7ea127eca51e3769009bfdac69a9c138fdff1c56b1352145c31e11773c746c079203d6562ac8b8cb135125a530",
"hex": "47304402201de00add2e25b64fb59a1b586478d1a561ddd40fa9265994025852d93e86c5dd02207c31dca9142105eddcc17c311cb0f48f28c8adcad27b6ae3d97d8dc05cfe0ec0014104b88c0ef1ec6f52fdf09e34e10ccec08076b23c7ea127eca51e3769009bfdac69a9c138fdff1c56b1352145c31e11773c746c079203d6562ac8b8cb135125a530"
},
"sequence": 4294967293
}
],
"vout": [
{
"value": 0.00570000,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 08e7ced2b0d09aff25cc8429d737e659b36811e5 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91408e7ced2b0d09aff25cc8429d737e659b36811e588ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1p66q9LKpifT99xPrks86WFxt8h4JTtcN"
]
}
},
{
"value": 0.00579000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 83f6dd568c924b6323769f31bf2997105c6e804f OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91483f6dd568c924b6323769f31bf2997105c6e804f88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1D2mFapJVNz87yV4CrXGab2kkFzWgB3xgc"
]
}
},
{
"value": 0.00600000,
"n": 2,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 84de7559c1e130d413dd29556b9d384dffa2afc5 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91484de7559c1e130d413dd29556b9d384dffa2afc588ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1D7Yh18fkSpuWeBKH7SFESuhsDYEQcUTUo"
]
}
},
{
"value": 0.00749091,
"n": 3,
"scriptPubKey": {
"asm": "OP_HASH160 1bfef4ccc0c996d78c4ce28a36cedc2c84b935db OP_EQUAL",
"hex": "a9141bfef4ccc0c996d78c4ce28a36cedc2c84b935db87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"34F3bPoSzWfN7B7sydLLyeHnY2igNtmwi7"
]
}
},
{
"value": 0.00797800,
"n": 4,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 8791d04d40ed443429ec485ed161efee507c686d OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9148791d04d40ed443429ec485ed161efee507c686d88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1DMpuD8VTiar9hXnfaQBqiRrRd3GmWCnpF"
]
}
},
{
"value": 0.00900000,
"n": 5,
"scriptPubKey": {
"asm": "OP_HASH160 11ced17f62b46f5d51a164d39771a368d9f00f9d OP_EQUAL",
"hex": "a91411ced17f62b46f5d51a164d39771a368d9f00f9d87",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"33KBAo7ANp3BqLoGsZfdSUJsgNxuRzsPik"
]
}
},
{
"value": 0.00943430,
"n": 6,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 0d9a72dc2c6c694c2feb45e2d069ea41905a51d9 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9140d9a72dc2c6c694c2feb45e2d069ea41905a51d988ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"12EvomzLHxdP2SUytDRKbaFx4zM2BGvHNM"
]
}
},
{
"value": 0.01000000,
"n": 7,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 0923dbf1ab22759b766c7aee2189f12850f80bbd OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9140923dbf1ab22759b766c7aee2189f12850f80bbd88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1qL3GLDp1LhvgUhPawfetgF8wCEN7gRTj"
]
}
},
{
"value": 0.01000000,
"n": 8,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 4f8a4b5f43436917222f7cf5fab8606d22805962 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9144f8a4b5f43436917222f7cf5fab8606d2280596288ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"18Fa428g3W92Nx4EnFAc7WHL1Lcn7uSKbK"
]
}
},
{
"value": 0.01000000,
"n": 9,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 a022007ab5e73500438a3c6820994f76c0f8294f OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914a022007ab5e73500438a3c6820994f76c0f8294f88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1FbhrBhFhqpAsH18BmjF2Afo5y343tMzUb"
]
}
},
{
"value": 0.01300000,
"n": 10,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 2bc8129b516eb7d3da4e42c3959bb600379297fb OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9142bc8129b516eb7d3da4e42c3959bb600379297fb88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"14zVjYTcA2si8pgbExLHKDu3mayPBoVR9w"
]
}
},
{
"value": 0.02046668,
"n": 11,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 da7d037a3d99e031d04097bfd2e410ac4769c976 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914da7d037a3d99e031d04097bfd2e410ac4769c97688ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1LvG4v5UqzgGVigAVRhdrPYPLE3QMPpQJF"
]
}
},
{
"value": 0.03600000,
"n": 12,
"scriptPubKey": {
"asm": "OP_HASH160 630681b6df2904ccd33bf4d6dd7ffe1894c696e1 OP_EQUAL",
"hex": "a914630681b6df2904ccd33bf4d6dd7ffe1894c696e187",
"reqSigs": 1,
"type": "scripthash",
"addresses": [
"3AiccdPS25KZyf5APKkdBiCfpRmuJL7FhZ"
]
}
},
{
"value": 0.05642274,
"n": 13,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 7c35c629bf20f15f14f6b6f5d8c18613821d11da OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9147c35c629bf20f15f14f6b6f5d8c18613821d11da88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1CKmD5Msa24q1URmfXoX8C8BJiZrdijFAS"
]
}
},
{
"value": 0.08146967,
"n": 14,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 ae5814cd6dd9898b0b6d0620c68d65091257f022 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914ae5814cd6dd9898b0b6d0620c68d65091257f02288ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1Gtr6NZQG68BrD3k1aXFWGSKDqrwfABBr9"
]
}
},
{
"value": 0.25000000,
"n": 15,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 101959fd4347ccda80305029cd9f03a3718fcf43 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914101959fd4347ccda80305029cd9f03a3718fcf4388ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"12U8BXPA4nxTcezbp1h2H8eXDR9jT8sSCG"
]
}
}
]
}
Am Anfang stehen Meta Informationen, wie die Transaktions-ID (TXID), die Größe in Byte etc.
Dann folgt ein Block mit Eingängen (vin), hier werden die Bitcoin die ausgegeben werden referenziert, jeweils über eine TXID und eine Position (vout). Der vout Wert ist wichtig da jede Transaktion mehr als einen Ausgang erzeugen kann. Es folgen asm und hex, welches jeweils die Signatur und der öffentliche Schlüssel für den jeweiligen Eingang sind unterschiedliche codiert.
Dann folgt ein Block mit Ausgängen (vout), hier werden Bitcoin ausgegeben. Jeder Ausgang erhällt eine Position (n). Es wird die Adresse und der Wert angegeben. Im asm Feld stehen die OP Codes die es erlauben diese Bitcoins später zu verwenden.
Die Gebühr ist Summe der Eingänge - Summe der Ausgänge und wird nicht explizit angegeben.
Die Transaktion wird nicht auf einen Server hochgeladen, sondern der Full Node verteilt sie an seine Peers. Diese Peers sind auch Full Nodes und überprüfen ob die Transaktion die Regeln des Netzwerks einhällt. Wenn sie die Regeln (sind im Quellcode hinterlegt) verletzt wird sie verworfen. Sollte ein peer zu oft ungültige Transaktionen senden wird es verbannt und keine Verbindung mehr aufgebaut. Full Nodes fanden ihre peers früher per IRC, inzwischen gibt es sogenannte Seed Nodes von denen ein Full Node von anderen Servern erfährt.
Miner sind auch Full Nodes die Rechenleistung aufwenden um Blöcke zu finden. Der erste gültige Block in dem eine Transaktion erhalten ist bestätigt die Transaktion. Jeder folgende Block erhöht die Anzahl der Bestätigungen, aber die Transaktion ist nicht nochmal Teil des Blocks. Wenn Miner einen Block gefunden haben, verteilen sie ihn an ihre Peers. Diese prüfen wieder. Gültig -> weiterreichen, ungültig -> verwerfen und zur Not bannen.
3. Der mysteriöse Block der die ganze Geschichte zusammenhält
- Wie besteht die Verbindung zwischen einem Hash Block und einer Transaktion?
Auch ein Block ist aufgeteilt. In einem Teil des Blocks dem Header befindet sich ein Teil einer Datenstruktur die Sich Baum nennt (Merkle Tree). Die Wurzel dieses (binären) Baums entsteht aus den paarweise gehashten Transaktions-IDs und ist Teil des Headers.
->
https://bitcoin.org/en/glossary/merkle-treeDamit ein Block als gültig akzeptiert wird muss er diverse Regeln befolgen, u.a. müssen alle Transaktionen gültig sein. Der rechenintensive Teil ist es das finden eines SHA256(SHA256(Block Header)) Hashes welcher der aktuellen Schwierigkeit genügt und den vorherigen Block referenziert. Diese wird vom Netzwerk automatisch alle 2016 Blöcke (ca. 2 Wochen) korrigiert um die Zeit zwischen zwei Blöcken im Schnitt auf 10 Minuten zu halten.
Die Grundlegende Idee nennt sich 'Proof-of-work' und gibt es schon länger als Bitcoin. Wenn du dir einen Hash Wert als binäre Zahl vorstellst, dann kann die erste Ziffer eine 1 oder eine 0 sein. Wenn du mir nun einen Hash zeigst der eine 0 am Anfang hat, dann kann ich davon ausgehen, dass du bis zu zwei unterschiedliche Datensätze gehasht haben musst um diesen Wert zu finden. Je mehr 0 bits ich fordere desto mehr Hashes wirst du im Mittel berechnet haben müssen um einen solchen vorzeigen zu können. Hier(!) kommt jetzt die nonce ins Spiel. Diese ist ein Wert im Header eines Bitcoin Blocks der verändert werden kann. Dieser Wert kann einfach hochgezählt werden um viele verschiedene Datensätze (mit jeweils gleichen Merkle Root und somit gleichen Satz an Transaktionen) testen zu können. Der nonce Wert sind nur 4 Byte, das reicht also bei den heutigen Terrahash ASICs nicht mehr aus. Es gibt aber weitere Felder im Header die bearbeitet werden können. Geprüft wird immer der Hash des Headers. Durch die Referenz auf den vorherigen Block entsteht eine Kette aus Blöcken, die Blockchain.
- Ist es richtig, dass im Moment 1 Block alle ca. 10 Minuten von allen Miner Weltweit generiert werden können was dem Output von Maximal 12.5 Bitcoins für alle Miner Weltweit in ~10 Minuten entspricht?
Jeweils im Mittel ja.
Also (ohne pools) defacto 1 einzige Person von allen 12.5 Bitcoins bekommt und alle anderen „leer ausgehen“? Oder habe ich da was falsch verstanden ¿¿¿
Die Bitcoin werden neu erzeugt und nicht empfangen. Dazu kommen die Gebühren der Transaktionen. Mit der Zeit wird es immer weniger neue Coins geben und die Gebühren werden immer wichtiger.
Wie unterscheidet sich die Prozedur (siehe oben „Minimal-Bitcoin-Miner“) von einem Pool als wenn man direkt über die Bitcoin Server arbeiten würde?
Die Rechenleistungsanforderungen einen Block in sinnvoller Zeit zu finden, sind inzwischen so hoch das es keine einzelne Maschine gibt die das noch kann. Also werden mehrere von diesen Maschinen genommen und die Arbeit wird unter ihnen aufgeteilt. Dazu gibt es entsprechende Protokolle die mit Bitcoin erstmal eigentlich nichts zu tun haben. Das ganze nennt man dann einen Pool. Ein Pool teilt sich in der Regel einen Full Node der das Ergebnis an den Rest des Netzwerks kommuniziert und die Arbeit aktualisiert wenn zwischenzeitlich jemand anderes einen Block gefunden hat.
Das war jetzt (auch für mich) ziemlich viel auf einmal. Frag gern weiter, aber es ist vermutlich besser einen Auspekt zur Zeit zu erklären und danach zu versuchen das ganze zusammen zu puzzeln.
