https://verde.flipstarter.cash
https://flipstarter.cash/
DONATE:
nexa:nqtsq5g5lrpa3xf3g4q4rwaj4qahdcc7tmudr3v9vhtrn30k
baby636#170473.8720380671✉
1LJS8qLyUn6Kq5m9nUtgrfuYBt8WFaJRpU
bitcoincash:qrfmvutyysfre5wxvv0wvhkxhrc8qwdkxuseg99xh3
baby636#217009.9792648302🦆
ecash:qrfmvutyysfre5wxvv0wvhkxhrc8qwdkxuf5uw7u3x
0x83bbc8c9768b5ec4288fdfd3e5383fdaa20cb4b3
Flipstarter-Logo Flipstarter
https://verde.flipstarter.cash
Die Finanzierung der Infrastruktur von Bitcoin Cash ist wichtig, und die Vielfalt der Infrastruktur schafft ein gesundes Ökosystem. Flipstarter bietet jedem Projekt die Möglichkeit, mit potenziellen Geldgebern auf eine Weise in Kontakt zu treten, die Rechenschaftspflicht für Projekte und Fairness für Geldgeber fördert.
In den letzten Jahren wurde Bitcoin Verde von einer kleinen Handvoll Entwickler gepflegt, die hofften, das BCH-Netzwerk durch Knotenvielfalt zu unterstützen. Wir sind Entwickler mit einer Leidenschaft für Software, die ihren Benutzern dient, indem sie ihrem Alltag einen echten Mehrwert bietet. Was als Bildungserfahrung, Entwicklung und Wartung von Bitcoin Verde begann, hat sich zu einem viel größeren Teil unseres Lebens entwickelt, als wir jemals hätten vorhersagen können. Wir sind Bitcoin Verde und in diesem Vorschlag haben wir ein wenig über uns selbst und was wir für unsere Implementierung sehen möchten, skizziert. In den folgenden Abschnitten werden wir die herausragendsten Funktionen, die als notwendig identifiziert wurden, um unseren Entwicklungspfad fortzusetzen und unsere Ziele zu erreichen, detailliert beschreiben. Unsere Hoffnung ist es, das Netzwerk weiterhin als Full-Node-Implementierung zu unterstützen und Bitcoin Verde letztendlich als praktikable Option für Miner bereitzustellen.
Die Kampagne wurde finanziert.
Aktie!Zelebrieren!fd4d68f48eb135db70979759c1ab2cbd9e88bed8407a274823262aa7d765ae8b
WER WIR SIND
Bitcoin Verde ist eine BCH-Full-Node-Implementierung, die von Josh Green, Inhaber von Software Verde, gegründet wurde. Software Verde ist eine Gruppe von Full-Stack-Softwareentwicklern aus Columbus, Ohio, die sich der Entwicklung von Technologien verschrieben haben, die unserer Community, unseren Kunden und Freunden dienen. Wir haben eine Affinität zu Open-Source-Software und sind im Allgemeinen alle lebenslange Technologie-Enthusiasten. Unser Team besteht hauptsächlich aus Josh Green, Andrew Groot, Eliot Lesar und John Jamiel. Wir begannen unsere Reise zur Schaffung von Bitcoin Verde Ende 2017, einige Monate nach der BCH-Hardfork. Wir waren bestrebt, einen Beitrag zu leisten, und beschlossen, „learning by doing“ zu lernen. Unsicher, wo er anfangen sollte, war Josh zu einer Erkenntnis gekommen; Die Mehrheit der Implementierungen waren Fork-Versionen desselben Bitcoin (Core)-Referenzclients. Wir haben dann entschieden, dass der beste Weg, wie wir beitragen können, während wir die Ins und Outs lernen, ein grundständiger Build ist. Bitcoin Verde trat dem Ökosystem im Januar 2019 bei und hatte schon immer das primäre Ziel, das BCH-Netzwerk zu diversifizieren. Wir glauben, dass wir dieses Ziel durch die Veröffentlichung unserer indizierten Java-Vollknotenimplementierung erreicht haben. Seit Beginn unserer Reise haben wir mit mehreren Gruppen, Technologen und anderen, zusammengearbeitet, um zur Gemeinschaft beizutragen, wo immer wir können. Die Teilnahme an unzähligen Diskussionen, die Aufklärung lokaler Regierungen, die Beauftragung von Bitcoin Unlimited zur Erstellung einer beschreibenden BCH-Spezifikation und die kontinuierliche Verbesserung unserer Implementierung sind Höhepunkte unserer Arbeit, auf die wir stolz sind. Wir haben in den letzten Jahren hart daran gearbeitet, sicherzustellen, dass die von uns geleistete Arbeit sinnvoll und wertvoll für unsere Gemeinschaft ist. Derzeit stellt Bitcoin Verde dem Netzwerk eine Vollknoten-Implementierung, einen Block-Explorer und eine Entwicklungsbibliothek zur Verfügung. Unsere Ambitionen für die Zukunft sind es, unsere Implementierung weiter zu verbessern und schließlich Wallet- und Mining-Pool-Module bereitzustellen.
UNSER ZIEL
Unser Ziel für diese Kampagne ist es, genügend Interesse und Unterstützung zu wecken, um unsere aktuelle Entwicklungs-Roadmap zu finanzieren. Derzeit hat Bitcoin Verde vier Kernfunktionen identifiziert, von denen wir glauben, dass sie notwendig sein werden, um weiterhin als wettbewerbsfähige, praktikable Option für BCH-Betreiber zu operieren, unabhängig davon, ob es sich um Full-Nodes oder Miner handelt. Zu diesen vier Merkmalen gehören:
Erstellen eines nicht indizierenden Moduls
Erstellen eines Blockvorlagen-Validierungsdienstes
Implementieren der Testnet-Konfiguration
Ändern des Bitcoin Verde Explorer: Memo-Unterstützung
DIE ARBEIT
ERSTELLEN EINES NICHT INDIZIERENDEN MODULS
Derzeit indiziert Bitcoin Verde große Teile der Blockchain. Einige dieser indizierten Komponenten umfassen (sind aber nicht beschränkt auf):
Alle Transaktionen
alle Ausgaben und Eingaben (sowohl ausgegeben als auch nicht ausgegeben)
P2PK/P2SH-Adressen
SLP-Token
SLP-Validierung
umstrittene/verwaiste Blöcke.
Obwohl diese Indizes für Explorer und Wallet-Dienste sehr nützlich sind, bieten sie viele Nachteile für Validierungsdienste und keinen wirklichen Wert für Mining-Knoten. Die Erstellung eines nicht-indizierenden Moduls für Bitcoin Verde wird mehrere Vorteile bieten, die letztendlich zu unseren Teamzielen beitragen würden, ein tragfähiges Mining-Modul zu werden. Zu den Vorteilen dieser Ergänzung gehören:
Reduzierung der Zeit für den anfänglichen Block-Download
Ermöglicht Mining-Pools, mit dem Betrieb eines Bitcoin Verde-Knotens in angemessener Zeit zu beginnen
Reduzierung der minimal erforderlichen Ressourcen
Reduziert die Eintrittsbarrieren sowohl für Miner als auch für nicht indizierende Node-Betreiber
Ermöglicht Pool-Betreibern, redundante/Backup-Knoten für ihren Pool zu geringeren Kosten auszuführen
Reduzierung der gesamten Infrastrukturkosten für den Betrieb eines Bitcoin Verde-Knotens
Die Lösung Mit cacheBlocks werden Blöcke serialisiert auf der Festplatte gespeichert. Viele der transaktions-, adressen- und slp-bezogenen SQL-Tabellen werden entfernt.
Es wird eine neue Transaktionstabelle mit Spalten erstellt, die verwendet werden können, um auf den Speicherort auf der Festplatte zu zeigen, an dem der Block der Transaktion gespeichert ist, und einen Offset, wo sich die Transaktion innerhalb der Block-Flatfile befindet.
Dadurch werden abgebaute Transaktionen aus der Datenbank (die indiziert und normalisiert ist, was platzsparend und weniger leistungsfähig ist) in ein kompakteres Format in einer Flatfile migriert.
Um die Mempool/Unconfirmed-Transaction-Logik zwischen den Modulen konsistent zu halten, werden die früheren Transaction_*-Tabellen umbenannt und für unbestätigte Transaktionen wiederverwendet.
Durch die Indizierung und Normalisierung unbestätigter Transaktionen kann Bitcoin Verde sein unbegrenztes Transaktionsverkettungslimit ohne zusätzliche Entwicklung beibehalten.
Wenn Transaktionen in einem Block abgebaut werden, werden sie aus der Tabelle „unconfirmed_transactions_*“ entfernt und nur in Block-Flatfiles gespeichert.
Da die Transaktions-SQL-Tabellen nicht groß sein werden, erhöht das Indizieren von nur unbestätigten Transaktionen nominell den Plattenbedarf des Knotens, während es immer noch eine Erweiterbarkeit für zukünftige Funktionen und komplexe Entscheidungen hinsichtlich der Aufnahme unbestätigter Transaktionen im nächsten Block ermöglicht.
Die Gesamttransaktionsgröße und der Gebührenbetrag werden der Transaktionstabelle hinzugefügt, um die Generierung von Blockvorlagen zu verbessern.
Änderungen wirken sich hauptsächlich auf die Datenschicht aus, die vom TransactionDatabaseManager und verwandten Klassen gekapselt ist. Validierungslogik und Netzwerklogik können minimal beeinträchtigt werden. Viele der bestehenden Tests hängen von der direkten Manipulation der Daten der Datenbank für ihren Aufbau ab. Bei einem anderen Schema werden diese Tests unterbrochen, wenn sie mit den Schemaänderungen für dieses Modul ausgeführt werden. Diese Schemaänderungen führen nicht dazu, dass die ursprüngliche Testsuite beschädigt wird, da die Testsuite standardmäßig das Indizierungsschema lädt. Bei dieser Konfiguration werden jedoch viele der Tests nicht mit dem neuen Schema ausgeführt, was zu einer ziemlich großen Lücke in der Testabdeckung für kritische Funktionen führt.
Dieser Vorschlag umfasst die Erweiterung bestehender Tests, um sowohl das nicht indizierende Schema als auch das indizierende Schema abzudecken.
Meilenstein, Ergebnisse und geschätzte Komplexität Wir haben geschätzt, dass diese Ergänzung ungefähr 180 Stunden Entwicklungszeit in Anspruch nehmen wird , um sie fertigzustellen. Unsere Lösung lässt sich in drei Hauptmeilensteine mit unterschiedlicher Komplexität unterteilen . Unser Vorschlag ist es, die Finanzierung proportional zur Komplexität und Zeit zuzuweisen, die für die Entwicklung dieser Meilensteine geschätzt werden, wobei die Finanzierung nach Abschluss jedes einzelnen erhalten wird.
SQL-Schema-Refaktorisierung und Datenschichtmigrationen. 80 / 180 Stunden (45%) Der erste Meilenstein wird aus den Änderungen des SQL-Schemas und der Logik bestehen, die in der Lösungsübersicht besprochen werden. Dieser Meilenstein gilt als abgeschlossen, sobald die Tabellen entfernt wurden und der Knoten seinen anfänglichen Block-Download im Hauptnetz erfolgreich abgeschlossen hat.
Aktualisierungstests für neue Datenschicht. 60 / 180 Stunden (33%) Der zweite Meilenstein besteht darin, alle fehlerhaften Tests zu aktualisieren, um sicherzustellen, dass vorhandene Regressionstests bestehen. Darüber hinaus umfasst der zweite Meilenstein die Erweiterung der bestehenden Testsuite, sodass sie sowohl für indizierende als auch für nicht indizierende Schemas ausgeführt werden kann.
Monatelange Main-Net-Tests liefen über den Block-Template-Aggregator. 40 / 180 Stunden (22%) Der dritte Meilenstein wird abgeschlossen, nachdem der Knoten mit dem Hauptnetz synchronisiert wurde und sein Vorlagenblock sowohl mit Bitcoin ABC- als auch mit Bitcoin Unlimited-Knoten kompatibel ist. Der Abschluss dieses Meilensteins erfordert, dass der Knoten für den neuen sigops-Regelsatz aktualisiert wird, der im Upgrade 2020-05 enthalten ist, und erfordert, dass der Vorlagenblockaggregator fertiggestellt wird, damit der von Bitcoin Verde generierte Vorlagenblock automatisch von anderen Knotenimplementierungen gegen den aktuellen Hauptknoten validiert werden kann -net-Knoten. Nach einem Monat der Erstellung von Hauptnetz-Vorlagenblöcken ohne Inkompatibilität gilt der Meilenstein als abgeschlossen.
BLOCKVORLAGEN-VALIDIERUNGSDIENST
Es besteht das Risiko, dass Blöcke, die von Minern abgebaut werden, eine Kettenspaltung verursachen oder verwaisen, weil sie zwischen Knotenimplementierungen nicht kompatibel sind. Aus Sicht eines Bergmanns kann selbst ein kleines Risiko im Zusammenhang mit diesen Inkompatibilitäten große Auswirkungen auf die Rentabilität haben. Dieses Inkompatibilitätsrisiko erhöht den Anreiz für Bergleute und Pools, alle dieselbe Implementierung auszuführen, was die Knotenvielfalt zwischen Bergleuten stark reduziert. Dieser Blockvorlagen-Validierungsdienst (TVS) zielt darauf ab, das Risiko, dass die Bergleute einen ungültigen Block erstellen, auf nahezu Null zu reduzieren, indem der Vorlagenblock gegen andere Implementierungen validiert wird, bevor Arbeiten an der Blockvorlage durchgeführt werden. Zu den Vorteilen dieser Arbeit gehören:
Reduzieren Sie das Risiko, dass ein Block unbeabsichtigt abgebaut wird, was zu einer Netzwerkaufspaltung führen würde
Reduzieren Sie das finanzielle Risiko für Miner, verschiedene Node-Implementierungen auszuführen
Erhöhen Sie das Vertrauen der Miner in die Knotenvielfalt
Warnen Sie Entwickler vor möglicherweise inkompatiblen Blöcken
Die Lösung Erstellen Sie einen Dienst, der mit der neuesten Version mehrerer Knotenimplementierungen verbunden ist ("validierende Knoten"):
BCHD
Bitcoin-ABC
Bitcoin unbegrenzt
Bitcoin Grün
Flowee Die Nabe
Dieser Dienst muss eine Standardblockvorlage von getblocktemplate akzeptieren, wie von BIP-22, BIP-23, BIP-9 und BIP-145 angegeben. Sobald eine Blockvorlage empfangen wurde, stellt der Dienst sicher, dass jeder validierende Knoten jede Transaktion innerhalb des Vorlagenblocks gesehen hat.
Der Dienst versucht dann, den Vorlagenblock für jede Implementierung zu validieren.
Der Dienst antwortet dann dem Anforderer, wenn ein Knoten die Vorlage für ungültig hält.
Der Dienst wird nach besten Kräften versuchen, festzustellen, welche Transaktion(en) den ungültigen Zustand des Vorlagenblocks auslösen, sodass der Anforderer sich dafür entscheiden kann, sie wegzulassen. Die Validierungsknoten sind möglicherweise nicht ausgestattet, um einen Vorlagenblock zu validieren. Diese Lösung wird
Definieren Sie einen formalen BIP, um getblocktemplate zu erweitern, damit sein Vorschlagsmodus einem Flag erlaubt, die Proof-of-Work-Validierung für die Blockdaten zu ignorieren.
Erstellen Sie eine Referenzimplementierung und eine Pull-Anforderung für Bitcoin ABC, die die obige Erweiterung für getblocktemplate erfüllt.
Bereitstellung einer Implementierung für Bitcoin ABC aufgrund seines derzeitigen Mehrheitsmarktanteils.
Wenn andere Implementierungen ähnliche erforderliche Funktionen bereitstellen, ohne getblocktemplate direkt zu verwenden, kann dieses Problem später erweitert werden, um Kompatibilitäts-Shims für diese Implementierungen zu erstellen.
Bitcoin Verde unterstützt derzeit nicht den Vorschlagsmodus von getblocktemplate. Dieses Problem wird die derzeit äquivalente Funktionalität so ändern, dass sie mit der getblocktemplate-RPC-API übereinstimmt, einschließlich des Vorschlagsmodus. Meilensteinschätzungen und Ergebnisse Wir haben geschätzt, dass diese Ergänzung ungefähr 160 Stunden Entwicklungszeit in Anspruch nehmen wird , um sie fertigzustellen. Unsere Lösung lässt sich in 4 Hauptmeilensteine mit unterschiedlicher Komplexität unterteilen . Unser Vorschlag ist es, die Finanzierung proportional zur Komplexität und Zeit zuzuweisen, die für die Entwicklung dieser Meilensteine geschätzt werden, wobei die Finanzierung nach Abschluss jedes einzelnen erhalten wird.
Definieren Sie die Dienst-API, um eine Blockvorlage zu validieren. 30/160 Stunden (18,75 %)
Rufen Sie mehrere RPC-getblocktemplate:proposal-Aufrufe an verbundene Knoten auf, um den Vorlagenblock zu validieren, und geben Sie den Validierungsstatus zurück. 30/160 Stunden (18,75 %)
Erstellen Sie einen formellen BIP, um die vorhandene Funktionalität von getblocktemplate:proposal zu erweitern. Und Referenzimplementierung für Bitcoin ABC. 60/160 Stunden (37,5 %)
Ändern Sie Bitcoin Verde, um den vorgeschlagenen BIP zu erfüllen. 40 / 160 Stunden (25%)
IMPLEMENTIEREN DER TESTNET-KONFIGURATION
Derzeit erlaubt Bitcoin Verde nur Verbindungen zum Mainnet. Während das Testen von Grenzfällen in der Vergangenheit größtenteils über Einheitentests mit öffentlichen Testvektoren durchgeführt wurde, gibt es zusätzliche Integrationstests, von denen Bitcoin Verde durch die Verbindung mit Testnet profitieren könnte, insbesondere in der Zeit vor Hard-Forks, in denen es den Anschein hat, dass Testnet mehr ist stark genutzt. Die Verbindung mit dem Testnetz kann auch eine Möglichkeit für die einzigartige Perspektive von Bitcoin Verde beim Testen von Bitcoin Cash bieten, um anderen Node-Implementierungen zugute zu kommen, falls die vielen Unterschiede zwischen Bitcoin Verde und anderen Implementierungen zu unterschiedlichen Arten von Testtransaktionen führen können. Einer der Hauptgründe, warum dies noch nicht implementiert ist, ist, dass Testnet eine Reihe von Unterschieden in Bezug darauf aufweist, wie Transaktionen und Blöcke weitergeleitet, validiert und abgebaut werden. Daher müssen diese Unterschiede alle umschaltbar basierend auf einem neuen Konfigurationsfeld implementiert werden. Diese Lösung bietet:
Ein zusätzlicher Testmodus, der Vorteile gegenüber aktuellen Modi bieten sollte.
Erhöhtes Risiko für Edge-Case-Transaktionen, die im Testnet weniger verboten sind.
Verbesserte Koordination mit anderen Node-Implementierungen für Hard-Fork-Tests.
Die Lösung Obwohl die Transaktionsstandardität derzeit nicht von Bitcoin Verde erzwungen wird, sollten auch Schritte unternommen werden, um sicherzustellen, dass, falls und wenn Standarditätsprüfungen zu Bitcoin Verde hinzugefügt werden, diese beim Verbinden mit dem Testnetz immer noch deaktiviert werden. Für den Betrieb mit dem Testnet sind folgende Updates erforderlich:
Alternative Portnummern, magische Nummern und DNS-Seeds
Unterschiedliche Versionsnummer und Präfix der Adresse
Unterschiedlicher Entstehungsblock
Zusätzliche Regeln zur Schwierigkeitsanpassung
Meilensteinschätzungen und Ergebnisse Wir haben geschätzt, dass diese Ergänzung ungefähr 60 Stunden Entwicklungszeit in Anspruch nehmen wird , um sie fertigzustellen. Dieser Zusatz kann in 2 Meilensteine unterteilt werden . Unser Vorschlag ist es, die Finanzierung proportional zur Komplexität und Zeit zuzuweisen, die für die Entwicklung dieser Meilensteine geschätzt werden, wobei die Finanzierung nach Abschluss jedes einzelnen erhalten wird.
Aktualisieren Sie Komponenten mit unterschiedlichen statischen Inhalten. 20 / 60 Stunden (33%) Der erste Meilenstein besteht aus den Änderungen, die nur für die Kommunikation mit dem BCH-Testnetz erforderlich sind. Dazu gehören Portnummern, alles, was den Inhalt von Protokollnachrichten beeinflusst, und Informationen über den Genesis-Block. Dieser Meilenstein gilt als abgeschlossen, sobald alle Komponenten aktualisiert und veröffentlicht wurden.
Stellen Sie sicher, dass eine vollständige Synchronisierung möglich ist. 40 / 60 (67%) Der zweite Meilenstein dieser Ergänzung erfordert, dass wir die Transaktions- und Blockvalidierungsregeln aktualisieren, um sicherzustellen, dass Bitcoin Verde tatsächlich die Inhalte akzeptiert, die es jetzt anfordern und empfangen kann. Erst wenn die vollständige Synchronisierung bestätigt wurde, wird dieser Meilenstein als abgeschlossen markiert.
ÄNDERN DES BITCOIN VERDE EXPLORERS
Der Bitcoin Verde-Knoten und -Explorer haben derzeit keine Unterstützung für Memo. Endbenutzer und Entwickler verlassen sich auf Block-Explorer, um die Gültigkeit ihrer Aktionen in der Blockchain zu überprüfen. Die Unterstützung durch den aktuellen Stand des Explorers wird als minimal angesehen, was Benutzer davon abhält, das volle Potenzial des Explorers auszuschöpfen. Die vollständige Unterstützung der von Benutzern durchgeführten SLP- und Memo-Aktionen würde eine praktikable Redundanz für andere Block-Explorer bieten und die Auswahl an Plattformen für Benutzer und diejenigen, die ihren eigenen Block-Explorer ausführen, erhöhen. Diese zusätzlichen Funktionen ermöglichen es anderen Entwicklern, leicht zu überprüfen, was Bitcoin Verde für gültig hält. Dies ist besonders wertvoll für OP_RETURN-ähnliche Anwendungen, da ihr Status nicht von Natur aus von Minern validiert wird. Insgesamt wird diese Änderung:
Ziehen Sie Benutzer für den Bitcoin Verde Explorer an, die das Memo-Protokoll für Nachrichten verwenden
Ermöglichen Sie anderen Entwicklern, die Gültigkeit ihrer OP_RETURN-basierten Transaktionen einfach zu überprüfen, um Implementierungen und Konsens zu validieren
Behalten Sie die Unterstützung für das alte Adressformat bei und fügen Sie gleichzeitig die CashAddr-Unterstützung hinzu
Die Lösung Memo-Unterstützung hinzufügen
Bitcoin Verde wird erweitert, um Memo-Protokolltransaktionen zu analysieren.
Memo-Transaktionen werden vom Knoten indiziert.
Es wird eine Routine implementiert, um die Indizes für aktuell synchronisierte Knoten zurückzuportieren.
RPC-Aufrufe werden aktualisiert, um Memo-Daten einzuschließen, ähnlich der für SLP bereitgestellten Funktionalität.
Die Explorer-API wird aktualisiert, um Transaktions-Memo-Daten aufzunehmen.
Der Explorer zeigt tabellierte Memo-Daten an, ähnlich wie bei bitcoin.com.
Meilensteinschätzungen und Ergebnisse Wir schätzen, dass diese Modifikationen etwa 56 Stunden Entwicklungszeit in Anspruch nehmen werden. Diese Änderung ist in 2 Hauptmeilensteine unterteilt , die jeweils unterschiedlich viel Komplexität aufweisen. Unser Vorschlag ist es, die Finanzierung proportional zur Komplexität und Zeit zuzuweisen, die für die Entwicklung dieser Meilensteine geschätzt werden, wobei die Finanzierung nach Abschluss jedes einzelnen erhalten wird.
Bitcoin Verde (Knoten) Memo-Unterstützung 40 / 56 Stunden (71,5 %) Der erste Meilenstein wird aus allen Knotenänderungen bestehen, die zur Unterstützung des Memo-Protokolls erforderlich sind, einschließlich RPC-Aufrufen. Dieser Meilenstein schließt die gesamte Memo-Unterstützung für den Explorer aus.
Bitcoin Verde (Node) Explorer Support 16 / 56 Stunden (28,5%) Der zweite Meilenstein WIRD aus allen Explorer-Änderungen bestehen, die zur Unterstützung des Memo-Protokolls sind.
ANGEFORDERTE FINANZIERUNG
Insgesamt WIRD der nächste Entwicklungszyklus für Bitcoin Verde nach unseren Schätzungen etwa 456 Stunden zwischen 3 unserer Ingenieure und 1 technischen Redakteur verlangt. Bei einer Rate von 0,6 BCH/h betrüge die beantragte Gesamtfinanzierung für diesen Vorschlag 273,6 BCH. Vor der Erstellung dieser Finanzierungskampagne hatte Josh Green jedoch individuelle Finanzierungsvorschläge für jedes Feature geschrieben, die als Einzelne Probleme auf GitHub verfolgt wurden. Nachdem bereits Mittel (24.838 BCH) zur Unterstützung dieses Entwicklungszyklus aufgebracht wurden, wäre es unverantwortlich, bereits geleistete Beiträge Nicht von ihren jeweiligen Erträgen abzuziehen. Nach Bereinigung um bereits erhaltene Beiträge beträgt die erhaltene Gesamtfinanzierung für diesen Zyklus 241.162 BCH oder ungefähr 62.000 USD ,
ANERKENNUNG
Die Durchführung dieses Projekts ist kein kleines Unterfangen. Es ist der anhaltende Großzügigkeit und Unterstützung unserer Gemeinschaft zu verdanken, dass wir unsere Aktivitäten heute fortsetzen können. Wir schätzen jede Gelegenheit, die uns das Netzwerk und alle Mitwirkenden angeboten haben, und freuen uns darauf, unser Engagement fortzusetzen. Wir freuen uns darauf, unser Engagement in der BCH-Community fortzusetzen und bei der Reifung unseres Netzwerks zu helfen.
Spenden
nexa:nqtsq5g5lrpa3xf3g4q4rwaj4qahdcc7tmudr3v9vhtrn30k
