diff --git a/_data/languages.yml b/_data/languages.yml index 9b2820d84..06c0a1f20 100644 --- a/_data/languages.yml +++ b/_data/languages.yml @@ -3,3 +3,4 @@ zh_CN: 简体中文 zh_TW: 繁體中文 ja: 日本語 es: Español +de: Deutsch diff --git a/_data/navigation.yml b/_data/navigation.yml index 89fc81dc0..4ccadc3aa 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -215,3 +215,48 @@ es: twitter_impersonation: title: "Twitter impersonation" # XXX url: "/en/twitter-impersonation" # XXX +de: + home: + title: "Bitcoin Core" + url: "/de/" + about: + title: "Über" + url: "/de/about/" + download: + title: "Download" + url: "/de/download" + blog: + title: "Blog" + url: "/de/blog/" + releases: + title: "Releases" + url: "/de/releases/" + dev: + title: "Entwicklung" + submenu: true + tree: + contribute: + title: "Mitmachen" + url: "/de/contribute/" + contribute-code: + title: "Code beitragen" + url: "/de/faq/contributing-code/" + meetings: + title: "Treffen" + url: "/de/meetings/" + eol: + title: "Lebenszyklus" + url: "/de/lifecycle" + contact: + title: "Kontakt" + submenu: true + tree: + contact_us: + title: "Kontaktiere uns" + url: "/de/contact/" + announcements: + title: "Ankündigungen" + url: "/de/list/announcements/join/" + twitter_impersonation: + title: "Twitter Imitation" + url: "/de/twitter-impersonation" diff --git a/_data/translations.yml b/_data/translations.yml index 1d2ed1937..4cc52cbbe 100644 --- a/_data/translations.yml +++ b/_data/translations.yml @@ -67,3 +67,17 @@ es: rss_feed: "Fuente RSS del Blog de Bitcoin Core" rss_meetings_feed: "Feed de reuniones" rss_blog_feed: "Feed de entradas del blog" + +de: + created: "Veröffentlicht am" + author: "von" + description: "Bitcoin Core Webseite" + footer: "Bitcoin Core Projekt" + related: "Empfohlen" + viewallposts: "Alle Beiträge anzeigen" + not_translated: "Hinweis: Diese Seite wurde noch nicht übersetzt" + tocoverview: "Übersicht" + translation_outdated: "Diese Übersetzung ist möglicherweise veraltet. Bitte mit der englischen Version vergleichen." + rss_feed: "Bitcoin Core Blog RSS-Feed" + rss_meetings_feed: "Besprechungs-Feed" + rss_blog_feed: "Blog-Posts-Feed" diff --git a/_posts/de/pages/2016-01-01-about.md b/_posts/de/pages/2016-01-01-about.md new file mode 100755 index 000000000..7f0d4f0a1 --- /dev/null +++ b/_posts/de/pages/2016-01-01-about.md @@ -0,0 +1,53 @@ +--- +title: Über +name: about +permalink: /de/about/ +type: pages +layout: page +lang: de +version: 3 +--- +## Über uns + +Bitcoin Core ist ein [Open-Source-Projekt](https://opensource.org/), +das einen Bitcoin-Software-Client namens "Bitcoin Core" pflegt und +veröffentlicht. + +Es ist ein direkter Nachkomme des ursprünglichen Bitcoin-Software-Clients, +der von Satoshi Nakamoto nach seinem berühmten Bitcoin-Whitepaper +veröffentlicht wurde. + +[Bitcoin Core](https://github.com/bitcoin/bitcoin) enthält "Full Node" +Software, um die Blockchain und die Bitcoin-Wallet vollständig zu +verifizieren. Das Projekt unterhält derzeit auch verwandte Software +wie die kryptografische Bibliothek [libsecp256k1](https://github.com/bitcoin-core/secp256k1) +und andere auf [GitHub](https://github.com/bitcoin-core). + +Jeder kann [zu Bitcoin Core beitragen](/de/contribute/). + +## Team + +Das Bitcoin Core-Projekt hat eine große Community von Open-Source-Entwicklern, +von denen viele gelegentlich zur Codebasis beitragen. +Und viele weitere die zur Forschung, Peer-Review, Tests, Dokumentation und +Übersetzung beitragen. + +### Betreuer + +Projektbetreuer haben Commit-Rechte und sind für das Zusammenführen von Patches +von Mitwirkenden verantwortlich. Sie fungieren als Torwächter und führen Patches +zusammen, die nach Meinung des Teams zusammengeführt werden sollten. Sie dienen +auch als Endkontrolle, um sicherzustellen, dass Patches sicher sind und den +Projektzielen entsprechen. Die Rolle der Betreuer wird von den Projektmitwirkenden erteilt. + +### Mitwirkende + +Es steht jedem frei, Codeänderungen vorzuschlagen sowie offene Pull-Requests +zu testen, zu überprüfen und zu kommentieren. Jeder, der Code, Review, Test, +Übersetzung oder Dokumentation zum Bitcoin Core Projekt beiträgt, gilt als Mitwirkender. +Die Versionshinweise für jede Bitcoin Core Softwareversion enthalten einen +Abschnitt "Credits", um all diejenigen zu danken, die im vorherigen +Veröffentlichungszyklus zum Projekt beigetragen haben. +Eine Liste der Code-Mitwirkenden findest du auf [Github][github-contributors]. + +{% include references.md %} diff --git a/_posts/de/pages/2016-01-01-blog.md b/_posts/de/pages/2016-01-01-blog.md new file mode 100755 index 000000000..04b1a4cea --- /dev/null +++ b/_posts/de/pages/2016-01-01-blog.md @@ -0,0 +1,9 @@ +--- +layout: post-index +title: Blog +name: blog +permalink: /de/blog/ +type: pages +lang: de +version: 1 +--- diff --git a/_posts/de/pages/2016-01-01-contribute.md b/_posts/de/pages/2016-01-01-contribute.md new file mode 100644 index 000000000..f5aebf368 --- /dev/null +++ b/_posts/de/pages/2016-01-01-contribute.md @@ -0,0 +1,46 @@ +--- +title: Wie kann ich mitmachen? +name: contribute +id: de-contribute +permalink: /de/contribute/ +type: pages +layout: page +lang: de +version: 5 +--- +Du bist herzlich eingeladen, dich an dem Projekt zu beteiligen! +Unser Hauptquellcode-Repository wird [auf GitHub gehostet](https://github.com/bitcoin/bitcoin/) + und es gibt mehrere Dinge, bei denen du helfen kannst: + + - Verbesserung unserer Dokumentation (siehe [README.md][README.md] und [doc folder][doc]) + - [Übersetzungen][translation_process.md] + - Code testen, Releases testen + - Beteilige dich an den Mailinglisten + - Verbesserung unserer Benutzeroberflächen + - Programmieren (offene Probleme beheben oder neue Funktionen implementieren) + +Du kannst gerne [Probleme][issues] melden und [Pull Requests][pulls] öffnen, +aber lese bitte die [Beitragsrichtlinien](/de/faq/contributing-code), um +unseren Arbeitsablauf zu verstehen. + +**Diskussion** + +Die meisten Bitcoin Core bezogenen Diskussionen finden in den folgenden +IRC-Kanälen auf irc.libera.chat statt: + +- [#bitcoin-core-dev] - Hauptdiskussion +- [#bitcoin-core-builds] - Build-System und Release Diskussion +- [#bitcoin-core-gui] - Diskussion zur grafischen Benutzeroberfläche + +Es gibt auch eine Mailingliste für Diskussionen über das Bitcoin-Protokoll [bitcoin-dev][]. + +**Trage zu dieser Website bei** + +Du kannst auch übersetzen oder anders zu dieser [Webseite][Website-Contrib] beitragen. + +[README.md]: https://github.com/bitcoin/bitcoin/blob/master/README.md +[doc]: https://github.com/bitcoin/bitcoin/tree/master/doc +[translation_process.md]: https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md +[website-contrib]: https://github.com/bitcoin-core/bitcoincore.org/blob/master/CONTRIBUTING.md + +{% include references.md %} diff --git a/_posts/de/pages/2016-01-01-index.md b/_posts/de/pages/2016-01-01-index.md new file mode 100755 index 000000000..db3acf4b9 --- /dev/null +++ b/_posts/de/pages/2016-01-01-index.md @@ -0,0 +1,13 @@ +--- +layout: home +type: pages +lang: de +title: Bitcoin +name: index +permalink: /de/ +version: 2 +tags: [bitcoin, bitcoin core] +translated: true +--- + +Bitcoin diff --git a/_posts/de/pages/2016-01-01-meetings.md b/_posts/de/pages/2016-01-01-meetings.md new file mode 100755 index 000000000..bb2b65d2d --- /dev/null +++ b/_posts/de/pages/2016-01-01-meetings.md @@ -0,0 +1,42 @@ +--- +type: pages +layout: page +lang: de +title: IRC-Treffen +name: meetings +permalink: /de/meetings/ +version: 4 +--- +Das Projekt veranstaltet mehrere wiederkehrende Treffen im `#bitcoin-core-dev` IRC +Kanal auf Libera Chat ([Webchat][bitcoin-core-dev-IRC-webchat]). Jeder ist herzlich +eingeladen, daran teilzunehmen. Protokolle und automatisch generierte Sitzungsprotokolle +findest du [hier][meetbot] und [hier][schnelli]. + +Aktuelle Treffen: + +- Allgemeines Entwicklertreffen: Donnerstag 19:00 UTC (jede Woche) +- Wallet Entwicklertreffen: Freitag 19:00 UTC (jede zweite Woche) +- P2P Entwicklertreffen: Dienstag 21:00 UTC (jede zweite Woche) + +Die Treffen sind auch in [diesem Google-Kalender][meeting calendar] aufgeführt. + +[Hier als ical-Format][meeting calendar ical] um über eine Kalender-App zu abonnieren. + +Wenn du Fragen zum Datum oder Uhrzeit eines bevorstehenden Treffens hast, +frage bitte im IRC-Kanal nach. + +Jeder, der daran interessiert ist, zu Bitcoin Core beizutragen, ist es auch +ermutigt, an den wöchentlichen Treffen des Bitcoin Core PR Review Club teilzunehmen, +die in einem anderen Chatroom stattfinden. Siehe [The Review Club +Webseite][review club] für Einzelheiten. + +Zusammenfassungen alter Treffen von 2015 bis 2018 sind jetzt [aufgeführt auf einer +separaten Seite][summaries]. + +[bitcoin-core-dev-IRC-webchat]: https://web.libera.chat/#bitcoin-core-dev +[meetbot]: http://www.erisian.com.au/meetbot/bitcoin-core-dev/ +[schnelli]: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/ +[meeting calendar]: https://calendar.google.com/calendar?cid=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ +[meeting calendar ical]: https://calendar.google.com/calendar/ical/11pqvdgpd99nlibf9ba861vu8s%40group.calendar.google.com/public/basic.ics +[review club]: https://bitcoincore.reviews/ +[summaries]: /de/meeting-summaries/ diff --git a/_posts/de/pages/2016-01-01-releases.md b/_posts/de/pages/2016-01-01-releases.md new file mode 100755 index 000000000..673a68cc8 --- /dev/null +++ b/_posts/de/pages/2016-01-01-releases.md @@ -0,0 +1,10 @@ +--- +type: pages +layout: page +lang: de +title: Releases +name: releases +permalink: /de/releases/ +version: 1 +--- +{% include releases.html %} diff --git a/_posts/de/pages/2016-01-13-supported-bips.md b/_posts/de/pages/2016-01-13-supported-bips.md new file mode 100644 index 000000000..a0803b816 --- /dev/null +++ b/_posts/de/pages/2016-01-13-supported-bips.md @@ -0,0 +1,12 @@ +--- +title: Bitcoin Core unterstützte BIPs +name: supported-bips +type: pages +layout: page +lang: de +permalink: /de/bips/ +version: 2 +--- +Bitcoin Core unterstützt folgende [BIPs][BitcoinCoreDocBips]. + +{% include references.md %} diff --git a/_posts/de/pages/2016-01-15-lifecycle.md b/_posts/de/pages/2016-01-15-lifecycle.md new file mode 100755 index 000000000..f7f6cc83c --- /dev/null +++ b/_posts/de/pages/2016-01-15-lifecycle.md @@ -0,0 +1,128 @@ +--- +title: Software-Lebenszyklus +name: software-life-cycle +id: en-software-life-cycle +permalink: /de/lifecycle/ +layout: page +type: pages +lang: de +version: 2 +--- +{% include toc.html %} + +Dieses Dokument beschreibt den Lebenszyklus des Bitcoin Core Softwarepakets, +das vom Projekt veröffentlicht wurde. Es entspricht der Standardwartungsrichtlinie +für kommerzielle Software. + +## Versionierung + +Bitcoin Core Releases sind wie folgt versioniert: 0.MAJOR.MINOR, und +Release-Kandidaten haben das Suffix rc1, rc2 usw. + +## Hauptversionen + +Unser Ziel ist es, alle 6-7 Monate eine Hauptversion herauszubringen. + +Diese werden mit 0.11.0, 0.12.0 usw. nummeriert. + +## Wartungsversionen + +Wir werden "Nebenversionen" für die Wartung bereitstellen, die Fehler in +den Hauptversionen beheben. Als allgemeine Regel führen wir keine größeren +neuen Funktionen in einer Wartungsversion ein (mit Ausnahme von Konsensregeln). +Wir werdeb jedoch bei Bedarf kleinere Funktionen hinzufügen, und Änderungen +der Konsensregeln wie Soft Forks. + +Nebenversionen werden mit 0.11.1, 0.11.2, 0.12.1, 0.12.2 usw. nummeriert. + +## Konsensregeln + +Vorschläge zur Änderung von Konsensregeln werden immer zuerst in Wartungsversionen +wie 0.11.2, 0.12.1 usw. ausgeliefert. Dies erleichtert es Unternehmen, den +Vorschlag zu bewerten und zu testen, da er im Vergleich zu einer Hauptversion +weniger Änderungen enthält. Es ermöglicht auch Benutzern, die einem konservativeren +Upgrade-Pfad folgen, Änderungen der Konsensregeln zeitnaher zu übernehmen. + +## Wartungszeitraum + +Wir warten die Hauptversionen bis zu ihrem "Wartungsende". Wir pflegen im +Allgemeinen die aktuelle und vorherige Hauptversion. +Wenn also die aktuelle Version 0.13 ist, dann wird auch 0.12 beibehalten. +Sobald 0.14 veröffentlicht wird, wird 0.12 als "Wartungsende" angesehen. +Je älter die Hauptversion, desto kritischer müssen die Probleme sein, um +darauf zurückportiert zu werden, und um eine neue Nebenversion zu rechtfertigen. +Sobald die Software den „Wartungsende“-Zeitraum erreicht hat, erhält sie +nur noch kritische Sicherheitsfixes bis zum End of Life „EOL“-Datum. +Nach EOL müssen Benutzer auf eine neuere Version aktualisieren, um Sicherheitsupdates +zu erhalten, auch wenn die Community eventuell Updates für kritische Probleme bereitstellen könnte. +Im Allgemeinen wird empfohlen, den neuesten Wartungsrelease (Point-Release) der +aktuellen oder vorherigen Hauptversion zu benutzen. + +Bitte beachte, dass Nebenversionen Bugfixes, Übersetzungsaktualisierungen +und Soft Forks erhalten. Die Übersetzung auf [Transifex][bitcoin-transifex-link] ist +nur für die letzten beiden Hauptversionen offen. + +Beispielsweise wurde die Hauptversion 0.9 am 19.03.2014 veröffentlicht, und wir +stellten bis zum 16.06.2015 Wartungskorrekturen (Point-Releases) bereit. +Kritische Sicherheitsprobleme würden weiterhin bis zum EOL-Datum 2016-02-28 behoben. +Um jedoch von Fehlerkorrekturen profitieren zu können, muss man auf eine neuere +Hauptversion aktualisieren. + +## Zeitplan + +Sobald EOL erreicht wurde, muss auf eine neuere Version aktualisieren. + +| Version | Veröffentlichungsdatum | Wartungsende | End of Life | +|---------|------------------------|--------------|-------------| +{% include posts/maintenance-table.md %} + +\* _Wir streben an, alle 6-7 Monate eine Hauptversion herauszubringen_ + +_TBA: wird noch bekannt gegeben_ + +## Protokollversionierung + +Die obige Beschreibung beschreibt nur Bitcoin Core Softwareversionen. Viele +andere Teile des Bitcoin-Systems enthalten ihre eigenen Versionen. Ein paar Beispiele: + +- Jede **Transaktion** enthält eine Versionsnummer. +- Das **P2P-Netzwerkprotokoll** verwendet Versionsnummern, damit Nodes ankündigen +können, welche Funktionen sie unterstützen. +- Die **integrierte Wallet** von Bitcoin Core hat eine eigene interne Versionsnummer. + +Diese Versionsnummern sind bewusst von der Versionsnummer von Bitcoin Core entkoppelt, +da das Bitcoin Core Projekt entweder keine direkte Kontrolle über sie hat +(wie es bei Blöcken und Transaktionen der Fall ist) oder versucht, die Kompatibilität +mit anderen Projekten aufrechtzuerhalten (wie es beim Netzwerk Protokoll der Fall ist) +oder lässt die Möglichkeit zu, dass in einigen Versionen keine größeren Änderungen +vorgenommen werden (wie dies manchmal bei der integrierten Wallet der Fall ist). + +Das Konsensprotokoll selbst hat keine Versionsnummer. + +## Beziehung zu SemVer + +Die Versionierung der Bitcoin Core Software folgt nicht dem optionalen Versionierungsstandard +[SemVer][], aber die Release-Versionierung ist oberflächlich ähnlich. SemVer wurde für die +Verwendung in normalen Softwarebibliotheken entwickelt, in denen Einzelpersonen die +Bibliothek in ihrem eigenen Tempo aktualisieren oder sogar auf einer älteren Version +zurückbleiben können, wenn ihnen die Änderungen nicht gefallen. + +Teile von Bitcoin, insbesondere die Konsensregeln, funktionieren so nicht. Damit +eine neue Konsensregel in Kraft treten kann, muss sie von einer bestimmten Anzahl +von Minern, Full Nodes oder beiden durchgesetzt werden und sobald sie in Kraft +getreten ist, kann Software, die die neue Regel nicht kennt, ungültige Transaktionen +generieren oder akzeptieren (obwohl Upgrades so konzipiert sind, dass dies nach +Möglichkeit verhindert wird). + +Aus diesem Grund weicht Bitcoin Core bei Änderungen an Konsensregeln und anderen +Aktualisierungen, bei denen eine netzwerkweite Übernahme notwendig oder wünschenswert +ist, von SemVer ab. Bitcoin Core veröffentlicht diese Änderungen als Wartungsversionen +(`0.x.y`) statt als Hauptversionen (`0.x.0`); Dadurch wird die Größe des Patches +minimiert, um es so vielen Personen wie möglich zu erleichtern, ihn zu inspizieren, +zu testen und bereitzustellen. Es ermöglicht auch, denselben Patch auf mehrere frühere +Hauptversionen zurückzuportieren, wodurch die Anzahl der Benutzer, die problemlos +aktualisieren können, weiter erhöht wird, obwohl es nicht immer genügend Freiwillige +gibt, um dies zu verwalten. + +[SemVer]: https://semver.org/ +[bitcoin-transifex-link]: https://www.transifex.com/bitcoin/bitcoin/ diff --git a/_posts/de/pages/2016-01-18-segwit-wallet-dev.md b/_posts/de/pages/2016-01-18-segwit-wallet-dev.md new file mode 100644 index 000000000..643c70404 --- /dev/null +++ b/_posts/de/pages/2016-01-18-segwit-wallet-dev.md @@ -0,0 +1,316 @@ +--- +version: 4 +title: Segregierter Witness Wallet-Entwicklungsleitfaden +name: segwit-wallet-dev +type: pages +layout: page +lang: de +permalink: /de/segwit_wallet_dev/ +--- +{% include toc.html %} +{% include references.md %} + +Die meisten Inhalte dieses Dokuments sind in den BIPs zu Segregated +Witness zu finden, einschließlich [BIP141][], [BIP143][], [BIP144][] +und [BIP145][]. Bitte betrachte dies als ersten Bezugspunkt zu anderen +verwandten Dokumenten und als Checkliste für das, was getan und was +nicht getan werden sollte. + +### Grundlegende Segregated Witness Unterstützung + +Eine Wallet MUSS alle Funktionen in diesem Abschnitt implementieren, +um auf einer grundlegenden Ebene als Segwit-kompatibel zu gelten: + +#### Senden an P2SH + +* Ein Segwit-kompatibles Wallet MUSS Pay-to-Script-Hash ([BIP16][]) +und das Adressformat ([BIP13][]) unterstützen. +* Für Zahlungen muss die Wallet in der Lage sein, eine bestimmte +P2SH-Adresse korrekt in einen scriptPubKey umzuwandeln +und eine Transaktion zu erstellen. +* Für den Empfang von Zahlungen muss die Wallet in der Lage sein, +eine P2SH-Adresse basierend auf einem P2WPKH-Skript (im Folgenden definiert) +zu erstellen und Zahlungen an solche Adressen zu erkennen. +* Dies ist eine zwingende Voraussetzung, auch wenn die Wallet nur +Single-Signatur-Zahlungen akzeptiert. + +#### Erstellung der P2SH-P2WPKH-Adresse + +* Eine P2SH-P2WPKH-Adresse ist vergleichbar mit der ursprünglichen + Single-Signature-P2PKH-Adresse von Bitcoin (Adresse mit Präfix 1). +* Wie jede andere P2SH-Adresse hat die P2SH-P2WPKH-Adresse das Präfix 3. +* Bis ein P2SH-P2WPKH-UTXO ausgegeben und das redeemScript + offengelegt wird, ist eine P2SH-P2WPKH-Adresse nicht von einer + Nicht-Segwit-P2SH-Adresse (z.B. einer Nicht-Segwit-Multi-Signatur-Adresse) + zu unterscheiden. +* P2SH-P2WPKH-Adressen sollten verwendet werden, wenn nur 1 öffentlicher + Schlüssel zum Empfangen von Zahlungen verwendet wird (wie P2PKH). +* P2SH-P2WPKH verwendet das gleiche öffentliche Schlüsselformat wie + P2PKH, mit einer sehr wichtigen Ausnahme: Der in P2SH-P2WPKH verwendete + öffentliche Schlüssel MUSS komprimiert sein, d.h. 33 Bytes groß sein + und mit einem 0x02 oder 0x03 beginnen. + Die Verwendung eines anderen Formats, wie z. B. eines unkomprimierten + öffentlichen Schlüssels, kann zu einem unwiderruflichen Geldverlust führen. +* So erstellt man eine P2SH-P2WPKH-Adresse: + 1. Berechne den RIPEMD160 des SHA256 eines öffentlichen Schlüssels + (keyhash). Obwohl die keyhash-Formel + dieselbe wie bei P2PKH ist, sollte die Wiederverwendung von + keyhash vermieden werden, um die Privatsphäre zu + verbessern und die versehentliche Verwendung eines unkomprimierten + Schlüssels zu verhindern. + 2. Das P2SH redeemScript ist immer 22 Bytes groß. + Es beginnt mit einem OP_0, gefolgt von einem canonical + push des keyhash (d.h. 0x0014{20-byte keyhash}). + 3. Wie bei jedem anderen P2SH ist scriptPubKey der + OP_HASH160 hash160(redeemScript) OP_EQUAL, und die + Adresse ist die entsprechende P2SH-Adresse mit dem Präfix 3. + +#### Transaktionsserialisierung + +* Eine Segwit kompatible Wallet MUSS das ursprüngliche Transaktionsformat + als nVersion|txins|txouts|nLockTime unterstützen. +* Eine Segwit kompatibles Wallet MUSS auch das neue Serialisierungsformat + unterstützen, als nVersion|marker|flag|txins|txouts|witness|nLockTime. +* Das Format von nVersion, txins, + txouts und nLockTime entspricht dem Originalformat. + * Die Marker MUSS 0x00 sein. + * Das Flag MUSS 0x01 sein. + * Der witness ist eine Serialisierung aller Witnessdaten der Transaktion. + * Jedem TXIN ist ein Witness-Feld zugeordnet. Daher gibt es + keine Angabe zur Anzahl der Witness-Felder, da dies durch die + Anzahl der txins impliziert wird. + * Jedes Witness-Feld beginnt mit einem compactSize + [integer](https://bitcoin.org/en/developer-reference#compactsize-unsigned-integers), + um die Anzahl der Stack-Elemente für das entsprechende txin + anzugeben. Es folgen dann ggf. Witness-Stack-Elemente für den + entsprechenden txin. + * Jedes Witness-Stack-Element beginnt mit einer Ganzzahl + compactSize, um die Anzahl der Bytes des Elements + anzugeben. + * Wenn ein txin mit keinen Witness-Daten verknüpft + ist, ist sein entsprechendes Witness-Feld exakt 0x00, + das gibt an, dass die Anzahl der Witness-Stack-Elemente null ist. +* Wenn alle txins in einer Transaktion nicht mit Witnessdaten + verknüpft sind, MUSS die Transaktion im ursprünglichen Transaktionsformat + serialisiert werden, ohne marker, flag und + witness. Wenn beispielsweise keines der txins + von segwit UTXO stammt, MUSS es im ursprünglichen Transaktionsformat + serialisiert werden. (Ausnahme: Coinbase-Transaktion) +* Beispiele für die Transaktionsserialisierung findest du im Beispielabschnitt + von BIP143. Wallet-Entwickler können die Beispiele verwenden, um zu testen, + ob ihre Implementierungen das neue Serialisierungsformat korrekt parsen. + +#### Transaktions-ID + +* Unter Segwit hat jede Transaktion 2 IDs. +* Die Definition von txid bleibt unverändert: das doppelte SHA256 + des ursprünglichen Serialisierungsformats. +* Eine neue wtxid wird definiert, die das doppelte SHA256 des neuen + Serialisierungsformats mit Witnessdaten ist. +* Wenn eine Transaktion keine Witnessdaten hat, ist ihre wtxid + dieselbe wie die txid. +* Die txid bleibt die primäre Kennung einer Transaktion: + * Es MUSS im txin verwendet werden, wenn auf einen vorherigen + Output verwiesen wird. + * Wenn eine Wallet oder ein Dienst derzeit txid verwendet, + um Transaktionen zu identifizieren, wird erwartet, dass du dies weiterhin mit segwit verwendest. + +#### Signaturgenerierung und -verifizierung für P2SH-P2WPKH + +* Für Outputs von Nicht-Segwit-UTXO bleibt der Signaturgenerierungsalgorithmus + unverändert. +* Für Outputs von P2SH-P2WPKH: + * Die scriptSig DARF NUR einen Push des redeemScript + enthalten. + * Das entsprechende Witness-Feld MUSS genau 2 Einträge enthalten, eine + Signatur gefolgt vom öffentlichen Schlüssel. + * Es gibt einen neuen Signaturgenerierungsalgorithmus, der in [BIP143][] + für Segwit-Skripte beschrieben wird. Entwickler sollten die Anweisungen + sorgfältig befolgen und das P2SH-P2WPKH-Beispiel in + [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#P2SHP2WPKH) + verwenden, um sicherzustellen, dass sie in der Lage sind, den + sighash zu reproduzieren. + * Der [BIP143][]-Signaturgenerierungsalgorithmus deckt den eingegebenen + Ausgabewert ab, was das Design von Air-Gap-Light-Weight-Wallets und + Hardware-Wallets vereinfacht. + * Bitte beachte, dass für ein P2SH-P2WPKH der scriptCode + immer 26 Bytes einschließlich des führenden Größenbytes ist, als + 0x1976a914{20-byte keyhash}88ac, NICHT das redeemScript + noch der scriptPubKey. + * [Beispiel](https://blockchainprogramming.azurewebsites.net/checktx?txid=8139979112e894a14f8370438a471d23984061ff83a9eba0bc7a34433327ec21). + +#### Netzwerkdienste (optional) + +* Netzwerkdienste werden benötigt, wenn die Wallet Transaktionen über das + Peer-to-Peer-Netzwerk senden und empfangen würde. +* Segwit fähige Nodes geben bekannt, dass sie Witnesses durch das Service + Bit bereitstellen können: NODE_WITNESS = (1 << 3) +* Transaktionen ohne Witnessdaten (und daher im Originalformat serialisiert) + können an Nodes mit oder ohne NODE_WITNESS-Unterstützung gesendet werden. +* Transaktionen, die Segwit-UTXOs ausgeben (und daher im neuen Format serialisiert werden), + DÜRFEN NUR an Nodes mit NODE_WITNESS-Unterstützung gesendet werden. +* Transaktionen, die Segwit-UTXOs ausgeben, aber mit vereinfachten Zeugendaten + (und daher im Originalformat serialisiert) werden möglicherweise an Nodes + ohne NODE_WITNESS-Unterstützung gesendet. Solche Transaktionen + sind jedoch nach der Aktivierung von segwit ungültig und würden nicht in einem + Block akzeptiert werden. +* Details zu den Netzwerkdiensten finden sich in [BIP144][]. + +#### Datenschutz der Benutzer + +* Bis Segwit-Transaktionen alltäglich sind, kann dieser Transaktionstyp + das Bitcoin-Tracking erleichtern. +* Die Verwendung von P2SH-P2WPKH als Standardänderungsausgabe kann sich auch + auf den Datenschutz auswirken. + +#### Schätzung der Transaktionsgebühr + +* Anstelle der Transaktionsgröße wird eine neue Metrik namens "virtual size" + (vsize) definiert. +* vsize einer Transaktion entspricht dem 3-fachen der Größe mit + ursprünglicher Serialisierung plus der Größe mit neuer Serialisierung, das + Ergebnis durch 4 teilen und auf die nächste ganze Zahl aufrunden. Wenn + beispielsweise eine Transaktion mit neuer Serialisierung 200 Bytes groß + ist und durch Entfernen von Marker, Flag und + Witness zu 99 Bytes wird, wird die vsize zu + (99 * 3 + 200) / 4 = 125 mit Aufrundung. +* vsize einer Nicht-Segwit-Transaktion ist einfach ihre Größe. +* Die Transaktionsgebühr sollte geschätzt werden, indem die vsize + mit anderen Transaktionen verglichen wird, nicht die Größe. +* Entwickler sollten darauf achten, bei der Schätzung der Gebühren keinen + "off-by-4-times" Fehler zu machen. + + +#### Aktivierung {#upgrade-safety} + +* Ab Blockhöhe 481824 begannen alle SegWit-fähigen Nodes mit der Einführung + der neuen SegWit-Konsensregeln. + +#### Rückwärtskompatibilität + +* Das Senden und Empfangen von Legacy-P2PKH-Zahlungen (Adresse mit Präfix 1) + sollte weiterhin unterstützt werden. + + +### Komplexe Skriptunterstützung + +Wenn ein Wallet andere Skripttypen als nur eine einzelne Signatur unterstützt, +wie z. B. Multi-Signatur, muss es mehr als die grundlegenden Anforderungen erfüllen: + +#### Erstellung der P2SH-P2WSH-Adresse + +* Eine P2SH-P2WSH-Adresse ist vergleichbar mit der ursprünglichen P2SH-Adresse + von Bitcoin, die die Repräsentation beliebig komplexer Skripte mit einer + Adresse mit fester Größe ermöglicht. +* Wie jede andere P2SH- und P2SH-P2WPKH-Adresse hat die P2SH-P2WSH-Adresse + das Präfix 3. Sie sind nicht zu unterscheiden, bis das UTXO ausgegeben wird. +* So erstellst du eine P2SH-P2WSH-Adresse: + 1. Definiere ein Skript namens (witnessScript). + 2. Berechne den SHA256 des witnessScript (scripthash). + Bitte beachte, dass ein einzelner SHA256 verwendet wird, kein doppelter + SHA256 oder RIPEMD160 (SHA256). + 3. Das P2SH redeemScript ist immer 34 Bytes groß. Es beginnt + mit einem OP_0, gefolgt von einem "canonical push" des + scripthash (d. h. 0x0020{32-byte scripthash}). + 4. Wie bei jedem anderen P2SH, der scriptPubKey ist + OP_HASH160 hash160(redeemScript) OP_EQUAL, und die Adresse + ist die entsprechende P2SH-Adresse mit dem Präfix 3. +* Einschränkungen des Skripts: + * Die Skriptauswertung darf nicht fehlschlagen und MUSS nach der Auswertung + ein und nur ein TRUE-Stack-Element hinterlassen. Andernfalls ist die + Auswertung fehlgeschlagen. + * Jeder öffentliche Schlüssel in P2SH-P2WSH-Skripten MUSS ein komprimierter + Schlüssel sein, sonst kann das Geld dauerhaft verloren gehen. + * Wenn OP_IF oder OP_NOTIF verwendet wird, MUSS das Argument entweder ein + leerer Vektor (für falsch) oder 0x01 (für wahr) sein. Die + Verwendung anderer Werte kann zu dauerhaften Geldverlusten führen. + ([BIP-Entwurf](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html)) + * Wenn ein OP_CHECKSIG oder OP_CHECKMULTISIG einen Fehler zurückgibt, + müssen alle Signaturen leere Vektoren sein. Andernfalls kann das Guthaben + dauerhaft verloren gehen. ([BIP146][]) + * Es gibt eine standardmäßige Begrenzung für das witnessScript + bei 3600 Bytes. Mit Ausnahme des witnessScript können höchstens + 100 Witness-Stack-Elemente mit jeweils höchstens 80 Bytes vorhanden sein. + Transaktionen, die diese Grenzen überschreiten, dürfen nicht weitergeleitet + oder in einen Block aufgenommen werden. + * Viele der ursprünglichen Konsensbeschränkungen für Skripte, wie z.B. 10000 + Bytes Skriptgröße, 201 nOpCount, gelten immer noch für P2SH-P2WSH. + * Die 520-Bytes-Skriptgrößenbeschränkung für P2SH gilt nicht für P2SH-P2WSH. + Es wird durch das Limit von 3600 Bytes und das Konsenslimit von 10000 Bytes ersetzt. + +#### Signaturgenerierung und -überprüfung für P2SH-P2WSH + +* Für P2SH-P2WSH Outputs: + * Die scriptSig DARF NUR einen Push des redeemScript enthalten. + * Das letzte Witness-Element des entsprechenden Witness-Feld MUSS das witnessScript sein. + * Der neue Signaturgenerierungsalgorithmus [BIP143][] wird angewendet: + * Ohne Verwendung von OP_CODESEPARATOR ist der scriptCode ein + witnessScript, dem eine compactSize-Ganzzahl für + die Größe von witnessScript. Wenn das Skript beispielsweise + OP_1 (0x51) ist, lautet der serialisierte scriptCode + (0x0151). + * Für alle ungewöhnlichen Skripte, die OP_CODESEPARATOR enthalten, lese + bitte [BIP143][] für die genaue Semantik. + * Alle Witness-Stack-Elemente vor dem witnessScript werden als + Eingabe-Stack für die Skriptauswertung verwendet. Der Eingabe-Stack wird + nicht als Skript interpretiert. Beispielsweise ist es nicht erforderlich, + einen 0x4c (OP_PUSHDATA1) zu verwenden, um ein großes Element zu "pushen". + * Um die Korrektheit der Signaturgenerierung und Stack-Serialisierung zu + überprüfen, teste bitte immer anhand der Beispiele in [BIP143][]. + * [Beispiel] (https://blockchainprogramming.azurewebsites.net/checktx?txid=954f43dbb30ad8024981c07d1f5eb6c9fd461e2cf1760dd1283f052af746fc88). + +### Segwit native Adressen (optional) {#advanced-designs} + +Die folgenden Funktionen sind für die anfängliche Segwit-Unterstützung nicht erforderlich. + +#### Native Pay-to-Witness-Public-Key-Hash (P2WPKH) + +* Natives P2WPKH ist ein scriptPubKey von 22 Bytes. Es beginnt + mit einem OP_0, gefolgt von einem "canonical push" des + keyhash (d. h. 0x0014{20-byte keyhash}). +* Wie bei P2SH-P2WPKH, keyhash ist RIPEMD160(SHA256) eines + komprimierten öffentlichen Schlüssels. +* Bei dem Output eines nativen P2WPKH MUSS scriptSig leer sein, + und das Witness-Stack-Format und die Signaturgenerierungsregeln sind dieselben + wie bei P2SH-P2WPKH (einschließlich der Anforderung, einen komprimierten + öffentlichen Schlüssel zu verwenden). +* [Beispiel](https://blockchainprogramming.azurewebsites.net/checktx?txid=d869f854e1f8788bcff294cc83b280942a8c728de71eb709a2c29d10bfe21b7c). + +#### Native Pay-to-Witness-Script-Hash (P2WSH) + +* Natives P2WSH ist ein scriptPubKey von 34 Bytes. Es beginnt + mit einem OP_0, gefolgt von einem "canonical push" des scripthash (d. h. 0x0020{32-byte scripthash}). +* Wie bei P2SH-P2WSH, scripthash ist SHA256 des witnessScript. +* Bei dem Output eines nativen P2WSH MUSS scriptSig leer sein, und + das Witness-Stack-Format und die Signaturgenerierungsregeln sind dieselben + wie bei P2SH-P2WSH (einschließlich der Anforderung, einen komprimierten + öffentlichen Schlüssel zu verwenden). +* [Beispiel](https://blockchainprogramming.azurewebsites.net/checktx?txid=78457666f82c28aa37b74b506745a7c7684dc7842a52a457b09f09446721e11c). + +#### Warum und wie werden native (Bech32) P2WPKH und P2WSH verwendet? + +* [BIP173][] schlägt ein Prüfsummen-Base32-Format (Bech32) für native P2WPKH- + und P2WSH-Adressen vor. +* Unterstützung für Bech32-Adressen war in Bitcoin Core v0.16.0 enthalten. +* Im Vergleich zu den P2SH-Versionen ist die Transaktions vsize der + nativen Versionen in den meisten Fällen kleiner, und daher kann eine geringere Gebühr anfallen. +* Natives P2WPKH und P2WSH können mit rohen scriptPubKey-Protokollen + wie dem Payment Protocol (BIP70) verwendet werden. Dies kann jedoch die + Privatsphäre des Zahlers und des Empfängers beeinträchtigen (siehe unten). +* Natives P2WPKH und P2WSH können als Standardänderungsadresse verwendet + werden, aber dies kann es anderen Personen ermöglichen, die Änderung leicht + zu identifizieren (siehe unten). +* Bis natives P2WPKH und P2WSH weit verbreitet sind, können diese Adresstypen + bei Benutzern Datenschutzbedenken hervorrufen. + + +### Beispiele für Skripts und Transaktionen + +* [Beispiele für verschiedene Witness-Transaktionstypen und Tools zur + Überprüfung der Transaktionsgültigkeit](https://blockchainprogramming.azurewebsites.net/checktx) +* [BIP141][] +* [BIP143][] +* [BIP173][] +* [Skripttests](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json) +* [Gültige Transaktionstests](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_valid.json) +* [Ungültige Transaktionstests](https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_invalid.json) diff --git a/_posts/de/pages/2016-03-12-contact.md b/_posts/de/pages/2016-03-12-contact.md new file mode 100755 index 000000000..533cdcce1 --- /dev/null +++ b/_posts/de/pages/2016-03-12-contact.md @@ -0,0 +1,42 @@ +--- +title: Kontaktiere uns +name: contact +permalink: /de/contact/ +type: pages +layout: page +lang: de +version: 2 +--- + +
+
+Bitcoin Core bietet +keinen technischen Support an. + +
Community-Support findest du unter +bitcoin.stackexchange.com +
+
+ + Twitter: +@bitcoincoreorg + +Du kannst Fehler in unserer Software über den +[Issue-Tracker][issues] melden. + +Du findest Bitcoin Core Entwickler auf [IRC][#bitcoin-core-dev]. + +## GPG keys + +Die folgenden Schlüssel können verwendet werden, um vertrauliche Informationen zu übermitteln +Entwickler: +{% include dev-keys.md %} +Um ein Problem mit dieser Website zu melden, verwende bitte den +[Webseiten Issue-Tracker][website-issues]. +
+Responsible Disclosure +
+Um Sicherheitsprobleme zu melden: security +@bitcoincore.org (nicht zur Unterstützung). +
+{% include references.md %} diff --git a/_posts/de/pages/2016-03-21-rss.md b/_posts/de/pages/2016-03-21-rss.md new file mode 100755 index 000000000..42ae5bf9d --- /dev/null +++ b/_posts/de/pages/2016-03-21-rss.md @@ -0,0 +1,25 @@ +--- +title: RSS Feeds +name: rss +permalink: /de/rss/ +type: pages +layout: page +lang: de +version: 2 +--- +

+Bitcoin Core Announcments RSS Feed +Feed für Sicherheitsankündigungen und Veröffentlichungsankündigungen (Englisch) +

+

+Bitcoin Core Blog RSS Feed +Blog-Posts-Feed (Englisch) +

+

+Bitcoin Core Meeting RSS Feed +Besprechungs-Feed (Englisch) +

+

+Bitcoin Core Releases RSS Feed +Releases-Feed (Englisch) +

diff --git a/_posts/de/pages/2017-01-01-download.md b/_posts/de/pages/2017-01-01-download.md new file mode 100644 index 000000000..822f15d18 --- /dev/null +++ b/_posts/de/pages/2017-01-01-download.md @@ -0,0 +1,142 @@ +--- +name: download +permalink: /de/download/ +type: pages +layout: page +lang: de +version: 5 + +## These strings need to be localized. In the listing below, the +## comment above each entry contains the English text. The key before the +## colon must not be changed; the value after the colon should be the +## translation. For example (Spanish): +## +## ## title: Download - Bitcoin +## title: Descargar - Bitcoin +# title: Download - Bitcoin +title: Download - Bitcoin +# latestversion: "Latest version:" +latestversion: "Neueste Version:" +# download: "Download Bitcoin Core" +download: "Download Bitcoin Core" +# downloados: "Or choose your operating system" +downloados: "Oder wähle dein Betriebssystem" +# download_sha: "SHA256 binary hashes" +download_sha: "SHA256-Binär-Hashes" +# download_sig: "SHA256 hash signatures" +download_sig: "SHA256-Hash-Signaturen" +# downloadtorrent: "Download torrent" +downloadtorrent: "Download torrent" +# source: "Source code" +source: "Quellcode" +# versionhistory: "Show version history" +versionhistory: "Versionsverlauf anzeigen" +# notelicense: "Bitcoin Core is a community-driven free software project, released under the open source MIT license." +notelicense: "Bitcoin Core ist ein von der Community betriebenes kostenloses Softwareprojekt das unter der Open-Source-MIT-Lizenz veröffentlicht wurde." +# notesync: > +# Bitcoin Core requires a one-time download of about $(DATADIR_SIZE)GB +# of data plus a further $(MONTHLY_RANGE_GB)GB per month. By default, +# you will need to store all of that data, but if you enable +# pruning, you can store as little as $(PRUNED_SIZE)GB total without +# sacrificing any security. +notesync: > + Bitcoin Core erfordert einen einmaligen Download von etwa $(DATADIR_SIZE)GB + an Daten plus weitere $(MONTHLY_RANGE_GB)GB pro Monat. Standardmäßig + musst du alle diese Daten speichern. Wenn du aber pruning + aktivierst, musst du insgesamt nur 2 GB speichern, ohne jegliche Sicherheit zu opfern. + +# full_node_guide: "For more information about setting up Bitcoin Core, please read the full node guide." +full_node_guide: "Weitere Informationen zum Einrichten von Bitcoin Core findest du in der Full Node Anleitung." +# patient: "Check your bandwidth and space" +patient: "Überprüfe deine Bandbreite und deinen Speicherplatz" + +pgp_key_fingerprint: "PGP key fingerprint" +verify_download: "Überprüfe deinen Download" + +verification_recommended: > +

Die Download-Verifizierung ist optional, wird aber dringend empfohlen. Die Durchführung der Verifizierungsschritte hier stellt sicher, dass du keine unerwartete oder manipulierte Version von Bitcoin heruntergeladen hast, was zu Geldverlusten führen kann.

+ +

Klicke auf eine der Zeilen unten, um die Bestätigungsanweisungen für jene Plattform zusehen.

+ +windows_instructions: "Anweisungen zur Windows-Verifizierung" +macos_instructions: "Anweisungen zur MacOS-Verifizierung" +linux_instructions: "Anweisungen zur Linux-Verifizierung" +snap_instructions: "Anweisungen zur Snap-Paket-Verifizierung" +download_release: "Klicke auf den Link in der obigen Liste, um die Version für deine Plattform herunterzuladen und warte bis der Download der Datei abgeschlossen ist." +download_checksums: "Lade die Liste der kryptografischen Prüfsummen herunter:" +download_checksums_sigs: "Lade die Signaturen herunter, die die Gültigkeit der Prüfsummen bestätigen:" +cd_to_downloads: "Öffne ein Terminal (Eingabeaufforderung) und ändere das Verzeichnis (cd) in den Ordner, der für Downloads verwendet wird. Zum Beispiel:" +cd_example_linux: "cd Downloads/" +cd_example_windows: > + cd %UserProfile%\Downloads + +verify_download_checksum: "Überprüfe mit dem folgenden Befehl, dass die Prüfsumme der Release-Datei in der Prüfsummendatei aufgeführt ist:" +checksum_warning_and_ok: 'In dem vom obigen Befehl erzeugten Output kannst du alle Warnungen und Fehler ignorieren, aber du mussst sicherstellen, dass die "$(SHASUMS_OK)" nach dem Namen der heruntergeladenen Versionsdatei ausgegeben wird. Zum Beispiel:' + +example_builders_line: "E777299FC265DD04793070EB944D35F9AC3DB76A Michael Ford (fanquake)" +builder_keys_url: "https://github.com/bitcoin/bitcoin/tree/master/contrib/builder-keys" + +obtain_release_key: > +

Bitcoin-Releases werden von einer Reihe von Personen signiert, von denen jede einen eindeutigen öffentlichen Schlüssel hat. Um die Gültigkeit von Signaturen zu erkennen, müsst du diese öffentlichen Schlüssel mit GPG lokal laden. In bitcoin/bitcoin repository, findest du viele Entwicklerschlüssel, die du dann in deine GPG-Schlüsseldatenbank laden kannst.

+ +

Zum Beispiel, anhand der + builders-key/keys.txt zeile + $(EXAMPLE_BUILDERS_LINE) kannst du diesen Schlüssel mit diesem Befehl laden:

+ +choosing_builders: > + Es wird empfohlen, dass du einige Personen aus dieser Liste auswählst, die du für vertrauenswürdig haltest, und ihre Schlüssel wie oben importierst oder alle Schlüssel gemäß den Anweisungen im contrib/builder-key + README. Später wirst du ihre Schlüssel verwenden, um die Signatur zu überprüfen, die die Gültigkeit der Prüfsummen bestätigt, die zum Überprüfen der Binärdateien verwendet wird. + +release_key_obtained: "Der Output des obigen Befehls sollte bestätigen, dass ein Schlüssel importiert, aktualisiert, neue Signaturen hat oder unverändert geblieben ist." + +verify_checksums_file: "Überprüfe, ob die Prüfsummendatei mit dem Release-Signaturschlüssel PGP-signiert ist:" + +check_gpg_output: > + Der obige Befehl gibt eine Reihe von Signaturprüfungen für jeden der öffentlichen Schlüssel aus, die die Prüfsummen signiert haben. Jede Signatur zeigt den folgenden Text an: + +line_starts_with: "Der beginn einer Zeile:" +complete_line_saying: "Eine komplette Zeile:" + +gpg_trust_warning: > + Der Output des Verifizierungsbefehls kann Warnungen enthalten: „key is not certified with a trusted signature.“. Das bedeutet, dass du zur vollständigen Verifizierung des Downloads bestätigen musst, dass der Fingerabdruck des Signaturschlüssels (z. B. $(SHORT_BUILDER_KEY)), der in der zweiten Zeile oben aufgeführt ist, mit dem übereinstimmt, was für den öffentlichen Schlüssel des Unterzeichners erwartet wird. + +localized_checksum_ok: "OK" +localized_gpg_good_sig: "Good signature" +localized_gpg_primary_fingerprint: "Primary key fingerprint:" + +install_gpg: "Wenn dz GNU Privacy Guard (GPG) noch nicht auf deinem System installiert hast," +gpg_download_page: "installieren es jetzt" +gpg_download_other: "oder sehe dir andere" +gpg_download_options: "Installationsoptionen an." + +snap_warning: > + Während die Snap-Pakete die statisch generierten ausführbaren Dateien verwenden, bietet das Snap-Tool selbst keine optimierte Möglichkeit, den Inhalt eines Snap-Pakets offenzulegen. Daher verfügt das Bitcoin Core Projekt nicht über die erforderlichen Informationen, um dir bei der Überprüfung der Bitcoin Core Snap-Pakete zu helfen. + +ensure_checksum_matches: > + Stelle sicher, dass die vom obigen Befehl erzeugte Prüfsumme mit einer der Prüfsummen übereinstimmt, die in der zuvor heruntergeladenen Prüfsummendatei aufgeführt sind. Wir empfehlen, jedes Zeichen der beiden Prüfsummen auf Übereinstimmung zu überprüfen. Du kannst die heruntergeladenen Prüfsummen anzeigen, indem du den folgenden Befehl ausführst: + +generate_checksum: "Führe den folgenden Befehl aus, um eine Prüfsumme der heruntergeladenen Versionsdatei zu generieren. Ersetze '$(FILE)' durch den Namen der Datei, die tatsächlich heruntergeladen wurde." + +build_reproduction: "Zusätzliche Verifizierung durch reproduzierbare Builds" +additional_steps: > + Erfahrene Benutzer, denen es nichts ausmacht, zusätzliche Schritte auszuführen, können die Vorteile der reproduzierbaren Builds von Bitcoin Core und der signierten Prüfsummen nutzen, die von Mitwirkenden generiert werden, die diese Builds ausführen. + +reproducible_builds: "Reproduzierbare Builds" +build_identical_binaries: > + Jedem mit einer Kopie des MIT-lizenzierten Quellcodes von Bitcoin Core erlauben, identische Binärdateien zu erstellen, die auf dieser Website verbreitet werden (was bedeutet, dass die Binärdateien dieselben kryptografischen Prüfsummen haben wie die von dieser Website bereitgestellten). + +verified_reproduction: "Geprüfte Reproduktion" +independently_reproducing: > + ist das Ergebnis mehrerer Bitcoin Core Mitwirkender, die jeweils unabhängig voneinander identische Binärdateien reproduzieren, wie oben beschrieben. Diese Mitwirkenden signieren und veröffentlichen die Prüfsummen der von ihnen generierten Binärdateien kryptografisch. +verifying_and_reproducing: > + Wenn du überprüfst, ob mehrere Mitwirkende, denen du vertraust, alle dieselben Prüfsummen signiert haben, die in der Release-Prüfsummendatei verteilt sind, erhälst du zusätzliche Sicherheit gegenüber den vorherigen grundlegenden Überprüfungsanweisungen. Alternativ bietet dir die Reproduktion einer Binärdatei für sich selbst die höchste derzeit verfügbare Sicherheit. Weitere Informationen findest du im Repository des Projekts von + +guix_repository: "vertrauenswürdige Build-Prozess-Signaturen" + +key_refresh: "Abgelaufene Schlüssel aktualisieren mit:" + +--- + +{% include templates/download.html %} diff --git a/_posts/de/pages/2017-01-01-twitter-impersonation.md b/_posts/de/pages/2017-01-01-twitter-impersonation.md new file mode 100644 index 000000000..10cc85af0 --- /dev/null +++ b/_posts/de/pages/2017-01-01-twitter-impersonation.md @@ -0,0 +1,53 @@ +--- +title: Twitter Imitation +name: twitter-impersonation +permalink: /de/twitter-impersonation/ +type: pages +layout: page +lang: de +version: 1 +--- +Uns sind mehrere Konten auf Twitter bekannt, die gegen [Twitter-Richtlinie zum Identitätsdiebstahl][] +verstoßen indem sie vorgeben, das Bitcoin Core Projekt oder +bekannte Personen, die mit Bitcoin Core in Verbindung stehen zu sein. Diese Konten +haben falsche und irreführende Informationen über Bitcoin Core und seine Mitwirkenden verbreitet. + +Wenn du eines dieser Konten siehst, kannst du es [an Twitter melden][]. Wenn +du ein Problem über das Bitcoin Core Projekt meldest und Twitter +bittet dich, die offizielle E-Mail-Adresse des Projekts anzugeben, verwende bitte: +contact@bitcoincore.org + +Dies scheint ein leider weit verbreitetes Problem auf Twitter zu sein, das auch viele +andere Projekte und Einzelpersonen betrifft, daher bitten wir dich dringend, alle Beiträge, +die du auf Twitter siehst---und anderswo--sorgfältig zu prüfen, um festzustellen, ob sie +wirklich oder nicht vom angegebene Absender stammen. + +Es ist besonders wichtig, bei Beiträgen vorsichtig zu sein, die dir empfehlen, eine Maßnahme +zu ergreifen, die möglicherweise Ihre Bitcoins oder Ihren Computer gefährden könnte, +wie z. B. der Vorschlag, eine neuere Version der Bitcoin-Software herunterzuladen. +Die neueste Version von Bitcoin Core kann immer von der [Download-Seite][] bezogen werden, +und für mehr Sicherheit wird empfohlen, die binäre Integrität mit PGP zu überprüfen +Anweisungen findest du im [Full Node Guide][]). + +Das Bitcoin Core Projekt wird dich niemals kontaktieren, um dich um +Informationen aus deiner Wallet, einschließlich deines Guthabens, deine Adressen, +Transaktionen oder privaten Schlüssel zu bitten. Wenn du eine Sicherheitsmitteilung erhälst und dir +nicht sicher bist, ob sie legitim ist oder nicht, kannst du dein Bitcoin Core Programm sicher +herunterfahren, um alle unmittelbaren Probleme zu beseitigen und um dir Zeit zum Nachforschen zu geben. + +Obwohl Bitcoin Core einen offiziellen Twitter-Account hat, +[@bitcoincoreorg][], alle wichtigen Ankündigungen zum Projekt werden auch an unsere +wenig frequentierte [Ankündigungs-Mailingliste][] gesendet oder auf der [Startseite dieser Webseite][] +(die auch einen [RSS-Feed][] hat). Wenn du mit der +Verwendung von PGP-Sicherheitssoftware vertraut bist, wird das Abonnieren der +Mailingliste besonders empfohlen, da alle Ankündigungen von einem Entwickler +kryptografisch signiert werden. + +[Twitter-Richtlinie zum Identitätsdiebstahl]: https://support.twitter.com/articles/18366# +[an Twitter melden]: https://support.twitter.com/forms/impersonation +[@bitcoincoreorg]: https://twitter.com/bitcoincoreorg +[Ankündigungs-Mailingliste]: /de/list/announcements/join/ +[Startseite dieser Webseite]: /de/ +[RSS-Feed]: /en/rss.xml +[Download-Seite]: /de/download +[Full Node Guide]: https://bitcoin.org/en/full-node diff --git a/_posts/de/pages/2020-08-01-meeting-summaries.md b/_posts/de/pages/2020-08-01-meeting-summaries.md new file mode 100755 index 000000000..43b748f84 --- /dev/null +++ b/_posts/de/pages/2020-08-01-meeting-summaries.md @@ -0,0 +1,14 @@ +--- +type: pages +layout: page +lang: de +title: Zusammenfassungen von IRC-Meetings +name: meeting-summaries +permalink: /de/meeting-summaries/ +version: 1 +--- +Von 2015 bis 2018 schrieben mehrere Freiwillige Zusammenfassungen von Bitcoin Core Entwicklungstreffen. Diese Seite verlinkt auf diese Zusammenfassungen. Informationen zu den letzten Meetings findest du auf der [Meetings-Seite][]. + +{% include meetings.html %} + +[Meetings-Seite]: /de/meetings/ diff --git a/_posts/de/pages/faq/2016-02-15-contributing-core-guidelines.md b/_posts/de/pages/faq/2016-02-15-contributing-core-guidelines.md new file mode 100755 index 000000000..520e24b7d --- /dev/null +++ b/_posts/de/pages/faq/2016-02-15-contributing-core-guidelines.md @@ -0,0 +1,16 @@ +--- +title: Wie man Code zu Bitcoin Core beisteuert +name: contributing-guidelines +id: en-contributing-guidelines +permalink: /de/faq/contributing-code/ +layout: page +type: pages +lang: de +category: faqs +version: 3 +--- +Das Bitcoin Core Projekt betreibt ein offenes Beitragsmodell, bei dem jeder +willkommen ist, zur Entwicklung in Form von Peer-Reviews, Tests und Patches beizutragen. + +Weitere Einzelheiten findest du im [Contribution Guide] +(https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md) im Git-Repository. diff --git a/_posts/de/pages/list/2016-03-10-announcements-join.md b/_posts/de/pages/list/2016-03-10-announcements-join.md new file mode 100755 index 000000000..f02a2819e --- /dev/null +++ b/_posts/de/pages/list/2016-03-10-announcements-join.md @@ -0,0 +1,18 @@ +--- +title: Abonniere Bitcoin Core Ankündigungen +name: announcements +permalink: /de/list/announcements/join/ +type: pages +layout: page +lang: de +version: 3 +--- +Erhalten Benachrichtigungen über wichtige Sicherheitsankündigungen und Veröffentlichungen für Bitcoin Core. + +Abonniere unten den RSS-Feed oder füge deine E-Mail-Adresse zur Mailingliste [bitcoin-core-dev][] hinzu. + +{% include pages/list/announcement.html %} + +Wenig Nachrichten, nur für Ankündigungen. + +{% include references.md %} diff --git a/_posts/de/posts/2022-04-25-release-23.0.md b/_posts/de/posts/2022-04-25-release-23.0.md new file mode 100644 index 000000000..447e516d2 --- /dev/null +++ b/_posts/de/posts/2022-04-25-release-23.0.md @@ -0,0 +1,30 @@ +--- +title: Bitcoin Core 23.0 released +name: blog-release-23.0 +id: en-blog-release-0.23.0 +lang: de +type: posts +layout: post + +## If this is a new post, reset this counter to 1. +version: 1 + +## Only true if release announcement or security annoucement. English posts only +announcement: 0 + +excerpt: > + Bitcoin Core 23.0 ist jetzt verfügbar. +--- +Bitcoin Core Version 23.0 ist jetzt zum [downloaden][download page] verfügbar. +Weitere Informationen zu den vielen neuen Funktionen und Fehlerbehebungen in +dieser Version findest du in den [Versionshinweisen][]. + +Wenn du Fragen hast, schaue bitte im IRC-Chatroom #bitcoin vorbei +([IRC][irc], [Web][web irc]) und wir werden unser Bestes tun, um dir zu helfen. + +[Versionshinweisen]: /en/releases/23.0/ +[IRC]: irc://irc.libera.chat/bitcoin +[web irc]: https://web.libera.chat/#bitcoin +[download page]: /de/download + +{% include references.md %} diff --git a/_posts/de/releases/2022-04-25-release-23.0.md b/_posts/de/releases/2022-04-25-release-23.0.md new file mode 100644 index 000000000..2b619e5cf --- /dev/null +++ b/_posts/de/releases/2022-04-25-release-23.0.md @@ -0,0 +1,428 @@ +--- +title: Bitcoin Core 23.0 +id: de-release-23.0 +name: release-23.0 +permalink: /de/releases/23.0/ +excerpt: Bitcoin Core Version 23.0 ist jetzt verfügbar +date: 2022-04-25 +type: releases +layout: page +lang: de + +## Use a YAML array for the version number to allow other parts of the +## site to correctly sort in "natural sort of version numbers". +## Use the same number of elements as decimal places, e.g. "0.1.2 => [0, +## 1, 2]" versus "1.2 => [1, 2]" +release: [23, 0] + +## Optional magnet link. To get it, open the torrent in a good BitTorrent client +## and View Details, or install the transmission-cli Debian/Ubuntu package +## and run: transmission-show -m +# +## Link should be enclosed in quotes and start with: "magnet:? +optional_magnetlink: "magnet:?xt=urn:btih:32bc317cce76b966a26bdb53d42f64d66d595954&dn=bitcoin-core-23.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969" + +# Note: it is recommended to check all links to ensure they use +# absolute urls (https://github.com/bitcoin/bitcoin/doc/foo) +# rather than relative urls (/bitcoin/bitcoin/doc/foo). +--- +{% include download.html %} +{% githubify https://github.com/bitcoin/bitcoin %} +23.0 Versionshinweise +================== + +Bitcoin Core Version 23.0 ist jetzt verfügbar unter: + + + +Diese Version enthält neue Funktionen, verschiedene +Fehlerbehebungen und Leistungsverbesserungen sowie aktualisierte Übersetzungen. + +Bitte melde Fehler über den Issue Tracker auf GitHub: + + + +Um Sicherheits- und Update-Benachrichtigungen zu erhalten, abonniere bitte: + + + +So aktualisierst du +============== + +Wenn du eine ältere Version verwendest, beende diese. Warten, bis es +vollständig heruntergefahren ist (was in einigen Fällen einige Minuten dauern kann), +führe dann das Installationsprogramm aus (unter Windows) oder kopiere es +einfach über `/Applications/Bitcoin-Qt` (auf Mac) oder +`bitcoind`/`bitcoin -qt` (unter Linux). + +Ein Upgrade direkt von einer Version von Bitcoin Core, die ihr EOL +erreicht hat, ist möglich, aber es kann einige Zeit dauern, wenn das +Datenverzeichnis migriert werden muss. Alte Wallet-Versionen von +Bitcoin Core werden im Allgemeinen unterstützt. + +Kompatibilität +============== + +Bitcoin Core wird auf Betriebssystemen mit Linux-Kernel, macOS +10.15+ und Windows 7 und neuer unterstützt und ausführlich getestet. +Bitcoin Core sollte auch auf den meisten anderen Unix-ähnlichen +Systemen funktionieren, es wird aber nicht so häufig auf ihnen +getestet. Es wird nicht empfohlen, Bitcoin Core auf nicht unterstützten +Systemen zu verwenden. + +Bemerkenswerte Änderungen +=============== + +P2P- und Netzwerkänderungen +----------------------- + +- Eine Bitcoin-Node wird standardmäßig keine Adressen mehr an + eingehende Peers weitergeben. Sie wird für Adressgespräche + berechtigt, nachdem sie eine ADDR-, ADDRV2- oder GETADDR-Nachricht + gesendet hat. (#21528) + +- Vor dieser Version hatte Bitcoin Core eine starke Präferenz, + sich nur mit Peers zu verbinden, die auf Port 8333 zuhören. + Infolgedessen würden Bitcoin-Knoten, die auf nicht standard Ports + zuhören, wahrscheinlich keine Bitcoin Core Peers verbindung erhalten. + Diese Einstellung wurde entfernt. (#23542) + +- Volle Unterstützung wurde für das CJDNS-Netzwerk hinzugefügt. + Siehe die neue Option `-cjdnsreachable` und [doc/cjdns.md](https://github.com/bitcoin/bitcoin/tree/23.x/doc/cjdns.md) (#23077) + +Gebührenschätzungs-Änderungen +---------------------- + +- Die Gebührenschätzung berücksichtigt jetzt die Gebühr für + Ersatztransaktionen (RBF). (#22539) + +Startparameter erneut scannen entfernt +-------------------------------- + +Der Startparameter `-rescan` wurde entfernt. Wallets, die aufgrund +von Beschädigungen erneut gescannt werden müssen, werden beim Start +weiterhin erneut gescannt. Andernfalls verwende bitte den RPC +`rescanblockchain`, um einen erneuten Scan auszulösen. (#23123) + +Tracepoints und Userspace, Support für statisch definierte Ablaufverfolgung +------------------------------------------------------------- + +Bitcoin Core Release-Binärdateien für Linux enthalten jetzt +experimentelle Tracepoints, die als Schnittstelle für prozessinterne +Ereignisse fungieren. Diese können für Überprüfung, Debugging, +Überwachung und mehr verwendet werden. Die Tracepoint-API ist +halbstabil. Während die API getestet wird, können sich Prozessinterna +zwischen Releases ändern, die Änderungen an den Tracepoints erfordern. +Informationen zu den vorhandenen Tracepoints findest du unte +[doc/tracing.md](https://github.com/bitcoin/bitcoin/blob/23.x/doc/tracing.md) +und Anwendungsbeispiele findest du hier: [contrib/tracing/](https://github.com/bitcoin/bitcoin/tree/23.x/contrib/tracing). + +Aktualisierte RPCs +------------ + +- Der `validateaddress` RPC gibt jetzt ein `error_locations` Array + für ungültige Adressen zurück, mit den Indizien ungültiger + Zeichenpositionen in der Adresse (falls bekannt). Dadurch wird + beispielsweise versucht, bis zu zwei Bech32 Fehler zu + lokalisieren und bei Erfolg ihre Positionen zurückzugeben. + Erfolg und Korrektheit sind nur dann gewährleistet, wenn + weniger als zwei substitution fehler gemacht wurden. Die + im Feld `Fehler` zurückgegebene Fehlermeldung gibt jetzt + auch spezifischere Fehler zurück, wenn die Dekodierung fehlschlägt. (#16807) + +- Die Konfigurationsoption `-deprecatedrpc=addresses` wurde + entfernt. Die RPCs `gettxout`, `getrawtransaction`, + `decoderawtransaction`, `decodescript`, `gettransaction verbose=true` + und die REST-Endpunkte `/rest/tx`, `/rest/getutxos`, `/rest/block` + geben die Felder `addresses` und `reqSigs`, die zuvor in 22.0 veraltet + waren, nicht mehr zurück. (#22650) +- Der RPC-Befehl `getblock` unterstützt jetzt verbosity Stufe 3, + die `prevout` Informationen von Transaktionseingaben enthält. Der + vorhandene REST-Endpunkt `/rest/block/` wird so geändert, dass er + auch diese Informationen enthält. Jedes `vin` Feld enthält ein + zusätzliches `prevout` Unterfeld, das den ausgegebenen Output beschreibt. + `prevout` enthält die folgenden Schlüssel: + - `generated` - wahr, wenn die ausgegebenen Coins eine Coinbase war. + - `height` + - `value` + - `scriptPubKey` + +- Die Top-Level-Gebührenfelder `fee`, `modifiedfee`, `ancestorfees` + und `descendantfees` zurückgegeben von RPCs `getmempoolentry`, + `getrawmempool(verbose=true)`, `getmempoolancestors(verbose=true)` + und `getmempooldescendants(verbose =true)` sind veraltet und werden + in der nächsten Hauptversion entfernt (verwende `-deprecated=fees`, + falls erforderlich). Auf dieselben Gebührenfelder kann über das + Objekt `fees` im Ergebnis zugegriffen werden. + WARNUNG: Die veralteten Felder `ancestorfees` und `descendantfees` + werden in Sats angegeben, während alle Felder im Objekt `fees` in + BTC angegeben werden. (#22689) + +- Sowohl `createmultisig` als auch `addmultisigaddress` enthalten + jetzt ein `warnings` Feld, das eine Warnung anzeigt, wenn ein + nicht-legacy-Adresstyp angefordert wird, wenn unkomprimierte + öffentliche Schlüssel verwendet werden.(#23113) + +Änderungen an Wallet bezogenen RPCs findest du im Abschnitt "Wallet" weiter unten. + +Neue RPCs +-------- + +- Informationen zum Soft-Fork-Status wurden von `getblockchaininfo` in + den neuen RPC `getdeploymentinfo` verschoben, der die Abfrage des + Soft-Fork-Status an jedem Block statt nur an der Kettenspitze ermöglicht. + Die Einbeziehung des Soft-Fork-Status in `getblockchaininfo` kann derzeit + mithilfe der Konfiguration `-deprecatedrpc=softforks` wiederhergestellt + werden, dies wird jedoch in einer zukünftigen Version entfernt. + Beachte, dass in beiden Fällen das Feld `Status` jetzt den Status des + aktuellen Blocks und nicht den des nächsten Blocks widerspiegelt. (#23508) + +Dateien +----- + +* Beim Start wird die Liste der gesperrten Hosts und Netzwerke (über `setban` RPC) + in `banlist.dat` ignoriert und nur `banlist.json` berücksichtigt. Bitcoin + Core Version 22.x ist die einzige Version, die `banlist.dat` lesen und auch + in `banlist.json` schreiben kann. Wenn `banlist.json` bereits vorhanden ist, + versucht Version 22.x nicht, `banlist.dat` in json zu konvertieren. Nach + einem Upgrade kann `listbanned` verwendet werden, um die geparsten Einträge + zu überprüfen. (#22570) + +Aktualisierte Einstellungen +---------------- + +- In früheren Versionen hat die Bedeutung der Befehlszeilenoption `-persistmempool` + (ohne Angabe eines Werts) die Mempool-Persistenz fälschlicherweise deaktiviert. + `-persistmempool` wird jetzt wie andere boolesche Optionen behandelt, dass + `-persistmempool=1` bedeutet. Das Übergeben von `-persistmempool=0`, + `-persistmempool=1` und `-nopersistmempool` ist davon nicht betroffen. (#23061) + +- `-maxuploadtarget` erlaubt jetzt menschenlesbare Byte-Einheiten [k|K|m|M|g|G|t|T]. + Z.B. `-maxuploadtarget=500g`. Leerzeichen, +- oder Brüche sind nicht erlaubt. + Der Standardwert ist `M`, wenn kein Suffix angegeben wird. (#23249) + +- Wenn `-proxy=` zusammen mit `-noonion` angegeben wird, wird der angegebene +Proxy nicht als Proxy zum Erreichen des Tor-Netzwerks benutzt. So wird es +beispielsweise mit dem RPC `addnode` nicht möglich sein, manuelle Verbindungen +zum Tor-Netzwerk zu öffnen. Um das alte Verhalten nachzuahmen, verwende +`-proxy=` zusammen mit `-onlynet=`, das alle relevanten Netzwerke außer +`onion` auflistet. (#22834) + +Werkzeuge und Hilfsmittel +------------------- + +- Aktualisiere `-getinfo`, um Daten in einem benutzerfreundlichen Format + zurückzugeben, das auch den vertikalen Platz reduziert. (#21832) + +- CLI `-addrinfo` gibt jetzt ein einzelnes Feld für die Anzahl der `onion` + Adressen zurück, die dem Node bekannt sind, anstelle separater `torv2` und + `torv3`Felder, da die Unterstützung für Tor V2-Adressen von Bitcoin Core + in 22.0 entfernt wurde. (#22544) + +Wallet +------ + +- Deskriptor-Wallets sind jetzt der Standard-Wallet-Typ. Neu erstellte Wallets + verwenden Deskriptoren, es sei denn, `descriptors=false` wird während `createwallet` + festgelegt oder die Option `Descriptor wallet` in dem GUI deaktiviert. + + Beachte, dass Wallet-RPC-Befehle wie `importmulti` und `dumpprivkey` + nicht mit Deskriptor-Wallets verwendet werden können. Wenn dein Client-Code + also auf diese Befehle angewiesen ist, ohne `descriptors=false` während der + Wallet-Erstellung anzugeben, muss dein Code aktualisiert werden. + +- Neu erstellte Deskriptor-Wallets enthalten einen automatisch generierten `tr()` + Deskriptor, der die Erstellung von "single key Taproot receiving addresses" ermöglicht. + +- `upgradewallet` leert jetzt automatisch den Schlüsselpool, wenn ein Upgrade von einer + Nicht-HD-Wallet auf eine HD-Wallet durchgeführt wird, um sofort mit der Verwendung + der neu generierten HD-Schlüssel zu beginnen. (#23093) + +- ein neuer RPC `newkeypool` wurde hinzugefügt, der den Schlüsselpool leert + (vollständig löscht und neu füllt). (#23093) + +- `listunspent` enthält jetzt `ancestorcount`, `ancestorsize` und + `ancestorfees` für jeden Transaktions-Output, die sich noch im Mempool befindet. + (#12677) + +- `lockunspent` nimmt jetzt optional einen dritten Parameter, `persistent`, + der bewirkt, dass die Sperre dauerhaft in die Wallet-Datenbank geschrieben wird. + Dadurch können UTXOs auch nach Neustarts oder Abstürzen des Nodes gesperrt bleiben. (#23065) + +- `receivedby` RPCs beinhalten jetzt Coinbase-Transaktionen. Zuvor schlossen + die folgenden Wallet-RPCs Coinbase-Transaktionen aus: `getreceivedbyaddress`, + `getreceivedbylabel`, `listreceivedbyaddress`, `listreceivedbylabel`. Diese + Version ändert dieses Verhalten und gibt Ergebnisse zurück, die empfangene + Coins von Coinbase-Outputs berücksichtigen. Das vorherige Verhalten kann + mit der Konfiguration `-deprecatedrpc=exclude_coinbase` wiederhergestellt + werden, wird aber möglicherweise in einer zukünftigen Version entfernt. (#14707) + +- Eine neue Option in denselben `receivedby` RPCs, `include_immature_coinbase` + (Standard = `false`), bestimmt, ob Transaktionen mit unreifen Coinbases + berücksichtigt werden. Unreife Coinbase-Transaktionen sind Coinbase-Transaktionen, + die 100 oder weniger Bestätigungen haben und nicht ausgegeben werden können. (#14707) + +GUI-Änderungen +----------- + +- UTXOs, die über die GUI gesperrt werden, werden jetzt dauerhaft in der + Wallet-Datenbank gespeichert, gehen also beim Herunterfahren oder Absturz + des Nodes nicht verloren. (#23065) + +- Die Bech32 Checkbox wurde durch ein Dropdown-Menü für alle Adresstypen + ersetzt, einschließlich des neuen Bech32m (BIP-350) Standards für Taproot-fähige Wallets. + +Low-Level-Änderungen +================= + +RPC +--- + +- `getblockchaininfo` gibt jetzt ein neues `time` Feld zurück, das die Kettenspitzenzeit liefert. (#22407) + +Tests +----- + +- Für das `regtest` Netzwerk wurden die Aktivierungshöhen mehrerer Softforks auf Blockhöhe 1 gesetzt. Das kann durch die Laufzeiteinstellung `-testactivationheight=name@height` geändert werden. (#22818) + +Credits +======= + +Vielen Dank an alle, die direkt zu dieser Veröffentlichung beigetragen haben: + +- 0xb10c +- 0xree +- Aaron Clauson +- Adrian-Stefan Mares +- agroce +- aitorjs +- Alex Groce +- amadeuszpawlik +- Amiti Uttarwar +- Andrew Chow +- Andrew Poelstra +- Andrew Toth +- anouar kappitou +- Anthony Towns +- Antoine Poinsot +- Arnab Sen +- Ben Woosley +- benthecarman +- Bitcoin Hodler +- BitcoinTsunami +- brianddk +- Bruno Garcia +- CallMeMisterOwl +- Calvin Kim +- Carl Dong +- Cory Fields +- Cuong V. Nguyen +- Darius Parvin +- Dhruv Mehta +- Dimitri Deijs +- Dimitris Apostolou +- Dmitry Goncharov +- Douglas Chimento +- eugene +- Fabian Jahr +- fanquake +- Florian Baumgartl +- fyquah +- Gleb Naumenko +- glozow +- Gregory Sanders +- Heebs +- Hennadii Stepanov +- hg333 +- HiLivin +- Igor Cota +- Jadi +- James O'Beirne +- Jameson Lopp +- Jarol Rodriguez +- Jeremy Rand +- Jeremy Rubin +- Joan Karadimov +- John Newbery +- Jon Atack +- João Barbosa +- josibake +- junderw +- Karl-Johan Alm +- katesalazar +- Kennan Mell +- Kiminuo +- Kittywhiskers Van Gogh +- Klement Tan +- Kristaps Kaupe +- Kuro +- Larry Ruane +- lsilva01 +- lucash-dev +- Luke Dashjr +- MarcoFalke +- Martin Leitner-Ankerl +- Martin Zumsande +- Matt Corallo +- Matt Whitlock +- MeshCollider +- Michael Dietz +- Murch +- naiza +- Nathan Garabedian +- Nelson Galdeman +- NikhilBartwal +- Niklas Gögge +- node01 +- nthumann +- Pasta +- Patrick Kamin +- Pavel Safronov +- Pavol Rusnak +- Perlover +- Pieter Wuille +- practicalswift +- pradumnasaraf +- pranabp-bit +- Prateek Sancheti +- Prayank +- Rafael Sadowski +- rajarshimaitra +- randymcmillan +- ritickgoenka +- Rob Fielding +- Rojar Smith +- Russell Yanofsky +- S3RK +- Saibato +- Samuel Dobson +- sanket1729 +- seaona +- Sebastian Falbesoner +- sh15h4nk +- Shashwat +- Shorya +- ShubhamPalriwala +- Shubhankar Gambhir +- Sjors Provoost +- sogoagain +- sstone +- stratospher +- Suriyaa Rocky Sundararuban +- Taeik Lim +- TheCharlatan +- Tim Ruffing +- Tobin Harding +- Troy Giorshev +- Tyler Chambers +- Vasil Dimov +- W. J. van der Laan +- w0xlt +- willcl-ark +- William Casarin +- zealsham +- Zero-1729 + +Sowie an alle, die bei Übersetzungen auf +[Transifex](https://www.transifex.com/bitcoin/bitcoin/) geholfen haben. +{% endgithubify %}