Pages:
Author

Topic: [ANN] BURST - Mining mit freiem Festplattenspeicher - P2P Markt, Crowdfunding .. - page 32. (Read 57375 times)

sr. member
Activity: 588
Merit: 252
Ist Ninja auf "deine" Chain aufgesprungen rico? Die waren mit ihren Blöcken doch schon ganz wo anders?
Ok, sieht schon wieder anders aus. Das ändert sich schnell, kackt bei ihnen scheinbar auch regelmäßig die Wallet ab.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Wäre es nicht möglich, Änderungen am Code vorzunehmen und so einen Fork zu produzieren, der mit den bestehenden Chains nicht mehr "kompatibel" ist? Also ich meine so was, wie jetzt BitCoin Cash macht um Replay Attacken zu vermeiden bei einem ChainSplit. Genau genommen wäre das, was ihr dann habt zwar nicht mehr Burst, sondern irgendein Fork. Aber wenn der sich als stabil heraus stellt, wird er ganz schnell der neue "offizielle" Burst.

Die Frage ist ob es dazu einen Fork braucht. Momentan sind die Probleme einfach nur auf Unzulänglichkeiten in der Implementation zurückzuführen.

So langsam bekommen einige Leute den Arsch hoch und machen was:

https://github.com/fuseburst/burstcoin/commit/cc51e673b70e4dfbca1a50e580712b648014d41f

Quote
added a new option burst.priorityBlockFeeders that takes a list of addresses. if that list exists, the client is guarenteed to take a look at each one of those address's blockchain at least once every 5 minutes(interval changeable). imo we need to get the pools talking to each other. right now they're picking random addresses from everyone they've talked to, and are talking to stuck/forked/ddossed/offline random clients instead of each other

Bzw. s.o. der muhatzg Branch.
bzw. unser MariaDB backend

Wie gesagt - in einer Woche kann viel passieren. Vielleicht haben wir bis dahin ja einen gestählten BURST client.
Egal ob ja oder nein, dann sehen wir weiter. Ne Woche will ich dem noch geben, damit man nicht sagen kann man hätte es nicht probiert/zu früh aufgegeben.

sr. member
Activity: 317
Merit: 251
Ich glaube, ich beginne so langsam zu verstehen welche Ausmaße das Schlamassel eigentlich hat.

Wir haben nicht nur ein Problem mit einem(?) Spammer und ziemlich inaktivem BURST Development.
Wir haben einen Coin auf Basis von NXT, welches selbst nicht gerade so vor Aktivität und Relevanz strotzt.

Damit das mal öffentlich dokumentiert ist:

Eine Woche intensive Betreuung gebe ich dem noch. Wenn bis dahin nicht absehbar ist, dass wir uns aus dem Schlammloch herausbewegen, dann werde ich meine Energie in etwas stecken, das mehr Zukunft verspricht. Ich hoffe es klingt nicht zu eingebildet, wenn ich mittlerweile der Ansicht bin, dass ich das so auch hinbekommen würde.  Wink

Ok - in einer Woche kann viel passieren. Schaumermal.
Wäre es nicht möglich, Änderungen am Code vorzunehmen und so einen Fork zu produzieren, der mit den bestehenden Chains nicht mehr "kompatibel" ist? Also ich meine so was, wie jetzt BitCoin Cash macht um Replay Attacken zu vermeiden bei einem ChainSplit. Genau genommen wäre das, was ihr dann habt zwar nicht mehr Burst, sondern irgendein Fork. Aber wenn der sich als stabil heraus stellt, wird er ganz schnell der neue "offizielle" Burst.
member
Activity: 70
Merit: 10
Danke.
Also die berechnete DL ist dann gleich, und das was im Bild angegeben ist, ist der gesetzte Parameter.
Alles klar, jetzt hab' ich's Smiley
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Falls in der ganzen Aufregung einer der Wissenden mir noch mal auf die Sprünge helfen kann:
Und zwar verstehe ich nicht, wieso die TargetDeadline bei
a) unterschiedlich
b) n/a bzw. unlimited

Weil das ein simpler Parameter ist, denn der Pool-Betreiber setzt. Sprich welche max DL er akzeptiert.
newbie
Activity: 5
Merit: 0
Von allen Leuten, die ich zum Thema Spam-Attacke gelesen habe, hatte der hier meiner Ansicht nach am meisten Ahnung: "muhatzg" Der hat seine Wallet selber modifiziert, das sie spam-proof ist und hat auch detailliert aufgezeigt, was er da warum gecodet hat. Gab auch schon positive Rückmeldungen dazu. Vielleicht ist es einen Versuch wert, wenn euch wie bei rico666 die Wallets immer noch abstürzen. -> https://github.com/muhatzg/burstcoin

Disclaimer: Ich hab voll keine Ahnung.

Schaue ich mir gerne an - bitte um einen Verweis auf die URL wo er das alles schreibt.

Das Abstürzen selbst ist mittlerweile nicht mehr das Hauptproblem, das haben wir dank meines Perl-10Zeilers im Griff.
MIttlerweile nerven mich zwei andere "Features". Einerseits, dass wir trotz angeblich verstopftem Netz fröhlich weiter Leerblöcke minen, zweitens, dass die Wallet ab und zu vollkommen eigenmächtig Blöcke von ihrer Blockchain entfernt (auto pop off). Ohne dass ich das steuern könnte.

Und dann natürlich, dass einige Entwickler, die JAVA buchstabieren können, hoch unqualifizierte Ansichten hierzu haben.  Undecided


Ich weiß, BurstNation ist böse, aber hier sind glaube ich nicht die üblichen Verdächtigen am Werk, sondern anscheinend Leute, die tatsächlich fixen wollen:

https://www.burstnation.com/wbb/index.php?thread/3526-possible-technical-explanation-for-the-constant-forking-and-ddos/&pageNo=9

Nebenbei: Hänge immer noch in dem burstmining.club drin. Miner sagt, der ist bei: "15:39:22 New block 385116, baseTarget 1454799, netDiff 12596 Tb"
member
Activity: 70
Merit: 10
Falls in der ganzen Aufregung einer der Wissenden mir noch mal auf die Sprünge helfen kann:
Und zwar verstehe ich nicht, wieso die TargetDeadline bei
- gleicher BlockNummer (BlockHeight)
- gleichem BaseTarget
- gleicher GenerationSignatur
a) unterschiedlich
b) n/a bzw. unlimited
sein kann. Die TargetDeadline wird doch aus den ersten drei genannten Daten berechnet, und wenn der Algo immer gleich ist (was ja nun Bedingung ist), dann muss das Ergebnis doch bei allen gleich sein.

Als Beispiel nehme ich einfach mal das von Antigo gepostete Bild; kann aber jedes andere sein, sind ja schon mehrere gepostet worden, und überall ist das unterschiedlich.
https://ip.bitcointalk.org/?u=https%3A%2F%2Fwww2.pic-upload.de%2Fimg%2F33596019%2Ffork.png&t=579&c=iDCKkliGmZr4Uw
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Von allen Leuten, die ich zum Thema Spam-Attacke gelesen habe, hatte der hier meiner Ansicht nach am meisten Ahnung: "muhatzg" Der hat seine Wallet selber modifiziert, das sie spam-proof ist und hat auch detailliert aufgezeigt, was er da warum gecodet hat. Gab auch schon positive Rückmeldungen dazu. Vielleicht ist es einen Versuch wert, wenn euch wie bei rico666 die Wallets immer noch abstürzen. -> https://github.com/muhatzg/burstcoin

Disclaimer: Ich hab voll keine Ahnung.

Schaue ich mir gerne an - bitte um einen Verweis auf die URL wo er das alles schreibt.

Das Abstürzen selbst ist mittlerweile nicht mehr das Hauptproblem, das haben wir dank meines Perl-10Zeilers im Griff.
MIttlerweile nerven mich zwei andere "Features". Einerseits, dass wir trotz angeblich verstopftem Netz fröhlich weiter Leerblöcke minen, zweitens, dass die Wallet ab und zu vollkommen eigenmächtig Blöcke von ihrer Blockchain entfernt (auto pop off). Ohne dass ich das steuern könnte.

Und dann natürlich, dass einige Entwickler, die JAVA buchstabieren können, hoch unqualifizierte Ansichten hierzu haben.  Undecided
newbie
Activity: 5
Merit: 0
Von allen Leuten, die ich zum Thema Spam-Attacke gelesen habe, hatte der hier meiner Ansicht nach am meisten Ahnung: "muhatzg" Der hat seine Wallet selber modifiziert, das sie spam-proof ist und hat auch detailliert aufgezeigt, was er da warum gecodet hat. Gab auch schon positive Rückmeldungen dazu. Vielleicht ist es einen Versuch wert, wenn euch wie bei rico666 die Wallets immer noch abstürzen. -> https://github.com/muhatzg/burstcoin

Disclaimer: Ich hab voll keine Ahnung.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Ich glaube, ich beginne so langsam zu verstehen welche Ausmaße das Schlamassel eigentlich hat.

Wir haben nicht nur ein Problem mit einem(?) Spammer und ziemlich inaktivem BURST Development.
Wir haben einen Coin auf Basis von NXT, welches selbst nicht gerade so vor Aktivität und Relevanz strotzt.

Damit das mal öffentlich dokumentiert ist:

Eine Woche intensive Betreuung gebe ich dem noch. Wenn bis dahin nicht absehbar ist, dass wir uns aus dem Schlammloch herausbewegen, dann werde ich meine Energie in etwas stecken, das mehr Zukunft verspricht. Ich hoffe es klingt nicht zu eingebildet, wenn ich mittlerweile der Ansicht bin, dass ich das so auch hinbekommen würde.  Wink

Ok - in einer Woche kann viel passieren. Schaumermal.
legendary
Activity: 1513
Merit: 1040
Quote
# My externally visible IP address or host name, to be announced to peers.
# It can optionally include a port number, which will also be announced to peers,
# and may be different from nxt.peerServerPort (useful if you do port forwarding behind a router).
nxt.myAddress=
Deine öffentliche IP oder Hostname (DDNS) wenn du keine statische IP hast.
Die Frage ist, was du vor hast?
sr. member
Activity: 854
Merit: 284
@ Rico
wie ich sehe sind wir gerade auf gleichen Chain Wink

nxt-default.properties - Frage:
sollte man vielleicht da doch den Eintrag in nxt.myAddress= ergänzen?

Wenn ja was kommt da rein: xxx.xxx.xxx.xxx:8123
sr. member
Activity: 854
Merit: 284
Mein Status zum 24.07.17

#WIN-10
Server 1.2.8 sowie Server 1.2.9b beide Stürzen immer wieder ab

#Linux-17.04
beide Server einigermaßen Stabil dennoch keine richtig laufende Mining Software Sad

#Version 1.2.9b (unter WIN)
heute Nacht habe es versucht die Blockchain zu Synchronisieren, es hat bis zu 22.02.2017 geklappt, es sind mittlerweile über 12 GB – Die Version ladet also eine Falsche Chain herunter ;(

also abwarten Tee trinken
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Kannst du kurz erklären wie das MySQL-Backend in der aktuellen Situation hilft? Ich vermute mal es ist schneller. Eventuell vermeidet es OOM-Fehler. Reicht das aus um das Netzwerk zu stabilisieren?

Man wird sehen was es hilft. Ziel ist eine Wallet die nicht immer abkackt. Jedenfalls kommen wir stabilen Nodes näher.

Es gibt auch lustige Momente:

https://imgur.com/VOeg9Avl.png
full member
Activity: 154
Merit: 100
Es gab hier Angebote von Leuten mit "dicken Maschinen und dicker Anbindung". Ich werde auf diese evtl. zurückkommen.
[...]
wir werden dann aber Leute brauchen, die die Wallet
installieren und Uploader spielen (min. 100MBit uplink, 40-64GB RAM, 50-100 Peers)
Ich könnte eventuell kurzzeitig was bereitstellen.

Quote
Wir haben mittlerweile eine BURST Wallet mit MySQL Backend am Laufen und werden diese jetzt so richtig stresstesten.
Wenn das tut, dann könnte das Problem bald gegessen sein -
Kannst du kurz erklären wie das MySQL-Backend in der aktuellen Situation hilft? Ich vermute mal es ist schneller. Eventuell vermeidet es OOM-Fehler. Reicht das aus um das Netzwerk zu stabilisieren?
legendary
Activity: 1120
Merit: 1037
฿ → ∞
ich hab eine dynamische ip adresse und den port von ausen nicht weitergeleitet sonst würde ich mehr hochladen und ich hab das hochladen auf 10 kb/sek begrenzt

Damit könntest Du die BURST Blockchain von einem Peer in 7.28 Tagen aktualisieren.  Cheesy

Es gab hier Angebote von Leuten mit "dicken Maschinen und dicker Anbindung". Ich werde auf diese evtl. zurückkommen.
Wir haben mittlerweile eine BURST Wallet mit MySQL Backend am Laufen und werden diese jetzt so richtig stresstesten.
Wenn das tut, dann könnte das Problem bald gegessen sein - wir werden dann aber Leute brauchen, die die Wallet
installieren und Uploader spielen (min. 100MBit uplink, 40-64GB RAM, 50-100 Peers)
legendary
Activity: 2450
Merit: 1004
ich hab eine dynamische ip adresse und den port von ausen nicht weitergeleitet sonst würde ich mehr hochladen und ich hab das hochladen auf 10 kb/sek begrenzt
legendary
Activity: 1120
Merit: 1037
฿ → ∞
das teil ist ein java programm und die laufen überall gleich gut bzw schlecht.
ich kann jetzt nur sagen unter windows mit der aktuellen Java runtime ist mir die wallet noch nicht abgestüzt und läuft schon seit 3 wochen durch
hab jetzt in den letzen tagen fast 20 GB hochgeladen

Bei mir stürzt es so alle 1-3 Stunden ab - hab jetzt in den lezten tagen so 1TB/ pro Tag hochgeladen...

Code:
2017-07-24 07:34:20 SEVERE: Error in blockchain download thread
java.lang.RuntimeException: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_129b/burst_db/burst.mv.db failed; file length -1 read length 1024 at 188480629 [1.4.196/1]"; SQL statement:
SELECT 1 FROM block WHERE id = ? [50000-196]
        at nxt.BlockDb.hasBlock(BlockDb.java:43)
        at nxt.BlockchainProcessorImpl$4.getCommonMilestoneBlockId(BlockchainProcessorImpl.java:493)
        at nxt.BlockchainProcessorImpl$4.run(BlockchainProcessorImpl.java:300)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)
Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_129b/burst_db/burst.mv.db failed; file length -1 read length 1024 at 188480629 [1.4.196/1]"; SQL statement:
SELECT 1 FROM block WHERE id = ? [50000-196]
        at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
        at org.h2.message.DbException.get(DbException.java:168)
        at org.h2.message.DbException.convert(DbException.java:295)
        at org.h2.command.Command.executeQuery(Command.java:215)
        at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:111)
        at nxt.BlockDb.hasBlock(BlockDb.java:39)
        ... 9 more
Caused by: java.lang.IllegalStateException: Reading from nio:/data/soft/lin/BURST/burst_129b/burst_db/burst.mv.db failed; file length -1 read length 1024 at 188480629 [1.4.196/1]
        at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
        at org.h2.mvstore.DataUtils.readFully(DataUtils.java:435)
        at org.h2.mvstore.FileStore.readFully(FileStore.java:98)
        at org.h2.mvstore.Page.read(Page.java:190)
        at org.h2.mvstore.MVStore.readPage(MVStore.java:1952)
        at org.h2.mvstore.MVMap.readPage(MVMap.java:741)
        at org.h2.mvstore.Page.getChildPage(Page.java:217)
        at org.h2.mvstore.Cursor.min(Cursor.java:129)
        at org.h2.mvstore.Cursor.hasNext(Cursor.java:36)
        at org.h2.mvstore.db.TransactionStore$TransactionMap$1.fetchNext(TransactionStore.java:1392)
legendary
Activity: 2450
Merit: 1004
das teil ist ein java programm und die laufen überall gleich gut bzw schlecht.
ich kann jetzt nur sagen unter windows mit der aktuellen Java runtime ist mir die wallet noch nicht abgestüzt und läuft schon seit 3 wochen durch
hab jetzt in den letzen tagen fast 20 GB hochgeladen
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Ein großes Problem sind abstürzende BURST Wallets. Leider betrifft das sowohl die 1.2.8 wie auch die 1.2.9b
Ich kenne nun nicht die Situation unter Windows, aber unter Linux ist das so. In anbetracht der Tatsache,
dass etliche pool Operatoren nach Linux migrieren wollen, gehe ich davon aus, dass unter Win die Sache
nicht besser ist.

Wer nun seine Wallet unter Linux betreibt, möchte sich vielleicht meinen BURST Wallet Watcher installieren:

https://pastebin.com/aEGpSTVH

Sehr simples Skript, startet die wallet, monitort deren Output, wenn da ne "SEVERE" Fehlermeldung kommt,
wird die Wallet neu gestartet. Tut nun seit 48 Stunden zuverlässig für die CryptoGuru Pool Wallet.
Pages:
Jump to: