Bitcoin SV (BSV, BCHSV)

[Jokin]

vor 50 Minuten schrieb DefinierMirCoin:

Das ist doch quatsch. Nur weil es keine Block-Obergrenze gibt, heißt dass nicht, dass jeder Miner gezwungen ist große Blöcke zu produzieren.
Das ist ist eine freie Entscheidung. Das spricht eher für BSV, die Wahl zu haben. Manche bleiben eben bei 1MB, manche gehen bis auf 300MB.
Freier Markt ...geht bei BTC nicht. 

Schon wieder falsch.

Auch bei BTC ist kein Miner gezwungen die Blöcke zu füllen.

Sie tun es dennoch weil sie dadurch mehr Profit machen.

Bei BSV gibt es jedoch einen guten Grund die Blöcke eben NICHT zu füllen.

Und wir sind uns doch wohl einig, dass es für eine Kryptowährung besser ist wenn möglichst viele anstehende Transaktiinen auch verarbeitet werden?

Zum Glück hat BSV auf 0-conf gesetzt, da ist es nicht so schlimm wenn Miner ihre Aufgabe nicht wahrnehmen.

[DefinierMirCoin]

vor 24 Minuten schrieb Jokin:

Auch bei BTC ist kein Miner gezwungen die Blöcke zu füllen.

Sie tun es dennoch weil sie dadurch mehr Profit machen.

Du meinst so wie dieser aktuelle 0 Block mit einer einzigen Transaktion? Eigentor! 😂
https://blockchair.com/bitcoin/block/632880

 

vor 1 Stunde schrieb Jokin:

Zum Glück hat BSV auf 0-conf gesetzt, da ist es nicht so schlimm wenn Miner ihre Aufgabe nicht wahrnehmen.

Das hat nichts mit Glück zu tun, das hat S.N. so von Anfang an geplant.

[fjvbit]

vor 13 Minuten schrieb DefinierMirCoin:

Du meinst so wie dieser aktuelle 0 Block mit einer einzigen Transaktion? Eigentor! 😂
https://blockchair.com/bitcoin/block/632880

Echt jetzt? 

Du nicht gesehen, dass da 2 Blöcke innerhalb von Sekunden gefunden wurden? 

[DefinierMirCoin]

vor 21 Minuten schrieb fjvbit:

Echt jetzt? 

Du nicht gesehen, dass da 2 Blöcke innerhalb von Sekunden gefunden wurden? 

Ich verstehe die Frage nicht.
Abgesehen davon, dass es Minuten waren und unterschiedliche Miner ... welche Rolle spielt das für die Größe?

[DefinierMirCoin]

Neues von unwriter für das Ecosystem: Transaction Tape

https://txt.network/#/

"TXT (Transaction Tape) is a portable Bitcoin transaction storage system which lets you store, manage, and share bitcoin transaction bundles with semantic metadata attached."

Damit lassen sich logisch zusammengehörende TX in Baum Strukturen speichern, mit Metadaten wie Tags und Channels versehen und eine FullText Suche gibt es gratis. Einfache Installation via Docker Image. Interessant dabei ist die mögliche Verwendung als Cache für die Merchant API Daten, die man bei Minern abfragen kann. Dann hätte man auch etwas in der Hand, falls ein Miner nicht ehrlich mit seiner Auskunft war.

 

[Jokin]

vor 32 Minuten schrieb DefinierMirCoin:

Dann hätte man auch etwas in der Hand, falls ein Miner nicht ehrlich mit seiner Auskunft war.

Wie sieht so eine "Unehrlichkeit" aus und warum sollten BSV-Miner dies tun?

vor 1 Stunde schrieb DefinierMirCoin:

Ich verstehe die Frage nicht.
Abgesehen davon, dass es Minuten waren und unterschiedliche Miner ... welche Rolle spielt das für die Größe?

Es waren Sekunden. Schau genau hin.

Und ja, natürlich kann das mal bei BTC passieren - während es bei BTC die Ausnahme ist, ist es bei BSV die Regel.

[Jokin]

Nachdem bei tocial und ANNE offenbar nix mehr passiert, gehen nun die Transaktionszahlen bei den Payment wieder hoch.

Selbstredend, dass das schon wieder künstlich angelegte Unsinnstransaktionen sind:

Das hatten wir schon vor Tocial und nun kommt das genauso wieder.

So ein Fake bei BSV!

[DefinierMirCoin]

vor 8 Minuten schrieb Jokin:

Wie sieht so eine "Unehrlichkeit" aus und warum sollten BSV-Miner dies tun?

BSV Miner tun das auch nicht, besonders die mit Miner ID nicht. Es könnte sich auf ihre Reputation auswirken
Aber, du weißt ja, es gibt immer schwarze Schafe, z.b. wenn ein unbekannter BTC Miner schlechtes Licht auf BSV werfen möchte, dann sind solche öffentlichen Überwachsmaßnahmen als Druckmittel zu verstehen.  Wobei es ja auch schon unwahrscheinlich ist, dass ein annoymer Miner eine Merchant API anbietet.

 

vor 16 Minuten schrieb Jokin:

Es waren Sekunden. Schau genau hin.

Ja dann habe ich wohl den falschen Blockexplorer benutzt, da sind halt 2 Minuten Unterschied zu sehen. 
Wie auch immer, ihr weicht meiner Frage aus, was die 2 Sekunden mit der Blockgröße zu tun hat.

[DefinierMirCoin]

Haha, der Luke Dash Jr. haut mal wieder Sachen raus:

Luke: "Objectively, each time you accept a bitcoin payment without verifying it with your own full node, you are harming Bitcoin's network security. Harming Bitcoin's security intentionally and with no good rationale could very well be described as an "attack"

Follower: Objectively, running a full node is not easy enough for mass adoption. I think that needs to be prioritized if we expect to change the ratio towards security.

Luke: That's why we should have reduced block sizes yesterday.

😂😂

Warum forkt er sich nicht einen eigenen coin mit 1 KB Blocksize. Das ist dann absolut und total sicher, weil es niemanden mehr gibt der den nutzt   

Bearbeitet 3. Juni 2020 von DefinierMirCoin

[Jokin]

vor 32 Minuten schrieb DefinierMirCoin:

wenn ein unbekannter BTC Miner schlechtes Licht auf BSV werfen möchte, dann sind solche öffentlichen Überwachsmaßnahmen als Druckmittel zu verstehen. 

Schön, dass auch Du nun ganz deutlich machst wozu diese Miner-ID eigentlich da ist.

Danke.

vor 17 Minuten schrieb DefinierMirCoin:

Warum forkt er sich nicht einen eigenen coin mit 1 KB Blocksize.

Weil er erkannt hat, dass Teamarbeit auch Kompromissfähigkeit bedeutet. 

Einfach seinen Dickkopf durchsetzen indem man sich absplittert, ist nicht sonderlich klug.

Dies zweimal zu tun ist ... Besonders Sonderbares Verhalten.

[DefinierMirCoin]

Wer hätte das gedacht, das tolle Lightning Network bringt weitere Sicherheitsprobleme mit sich. 

Time-Dilation Attacks on the Lightning Network
https://arxiv.org/abs/2006.01418

Abstract
"According to our measurements, it is currently possible to steal the total channel capacity by keeping a node eclipsed for as little as 2 hours. Since trust-minimized Bitcoin light clients currently connect to a very limited number of random nodes, running just 500 Sybil nodes allows an attacker to Eclipse 47\% of newly deployed light clients (and hence prime them for an attack). As for the victims running a full node, since they are often used by large hubs or service providers, an attacker may justify the higher Eclipse attack cost by stealing all their available liquidity.

In addition, time-dilation attacks neither require access to hashrate nor purchasing from a victim. Thus, this class of attacks is a more practical way of stealing funds via Eclipse attacks than previously anticipated double-spending"

...

Conclusion
"Even though Lightning Network has the potential to address the scalability limitations of Bitcoin, it introduces new security assumptions. In this work we explored how they hold in practice. More specifically, we explored what can be done when an attacker isolates (eclipses) a user of the Lightning Network, and feeds blocks to the victim at a slower rate. We showed that time-dilation cannot be addressed by simply detecting slow block arrival, and implementing sophisticated detection measures is not trivial. We argued that time-dilation attacks are currently the most practical way of stealing funds via Eclipse attacks since time-dilation attacks do not require access to hashrate and an attacker doesn’t have to purchase anything from a victim. The Eclipse attack cost can be justified against both light clients (the cost is low) and full nodes (an attacker may steal all liquidity of wealthy nodes at once). Finally, we suggested that strong anti-Eclipse/anti-Sybil measures (e.g. alternative sources of blocks) is the key to significantly reducing the risks of time-dilation attacks.

 

Zum Glück steht auch drin, was man dagegen tun kann:
Higher connectivity and the number of honest reachable nodes.  ==>  Hier musste ich wirklich lachen, in Anbetracht der letzten Diskussionen. Hörst du @PeWi , ein sicheres LN basiert auf honest Nodes   

[fjvbit]

vor 3 Stunden schrieb DefinierMirCoin:

Wer hätte das gedacht, das tolle Lightning Network bringt weitere Sicherheitsprobleme mit sich. 

Time-Dilation Attacks on the Lightning Network
https://arxiv.org/abs/2006.01418

Abstract
"According to our measurements, it is currently possible to steal the total channel capacity by keeping a node eclipsed for as little as 2 hours. Since trust-minimized Bitcoin light clients currently connect to a very limited number of random nodes, running just 500 Sybil nodes allows an attacker to Eclipse 47\% of newly deployed light clients (and hence prime them for an attack). As for the victims running a full node, since they are often used by large hubs or service providers, an attacker may justify the higher Eclipse attack cost by stealing all their available liquidity.

In addition, time-dilation attacks neither require access to hashrate nor purchasing from a victim. Thus, this class of attacks is a more practical way of stealing funds via Eclipse attacks than previously anticipated double-spending"

...

Conclusion
"Even though Lightning Network has the potential to address the scalability limitations of Bitcoin, it introduces new security assumptions. In this work we explored how they hold in practice. More specifically, we explored what can be done when an attacker isolates (eclipses) a user of the Lightning Network, and feeds blocks to the victim at a slower rate. We showed that time-dilation cannot be addressed by simply detecting slow block arrival, and implementing sophisticated detection measures is not trivial. We argued that time-dilation attacks are currently the most practical way of stealing funds via Eclipse attacks since time-dilation attacks do not require access to hashrate and an attacker doesn’t have to purchase anything from a victim. The Eclipse attack cost can be justified against both light clients (the cost is low) and full nodes (an attacker may steal all liquidity of wealthy nodes at once). Finally, we suggested that strong anti-Eclipse/anti-Sybil measures (e.g. alternative sources of blocks) is the key to significantly reducing the risks of time-dilation attacks.

 

Zum Glück steht auch drin, was man dagegen tun kann:
Higher connectivity and the number of honest reachable nodes.  ==>  Hier musste ich wirklich lachen, in Anbetracht der letzten Diskussionen. Hörst du @PeWi , ein sicheres LN basiert auf honest Nodes   

Genau, du verstehst den Text? 

Es geht darum, dass sich Light LN-Clients, mit bösen Nodes verbinden und sie anschließend isoliert werden. 

Du hast LN immer noch nicht getestet? 

Meine LN Light Clients verbinden sich nicht mit zufälligen Nodes. Und natürlich ist es wichtig, dass man nur guten Nodes vertrauen sollte. Ein prima Argument für Bitcoin und gegen BSV, wo man leicht seinen eigenen Fullnode auf einem Raspberry fahren kann. Einer meiner beiden mobilen Light LN Client verbindet sich nur mit meiner eigenen Fullnode. Ein andere nur zur Node vom Hersteller (Phoenix LN Node) ... 

Wie soll da bitte einer dazwischen kommen können und die Nodes isolieren? 

Ich rate dir, probiere LN aus, dann verstehst du es vielleicht... 

Und natürlich sind "honest Nodes" wichtig. Nodes nicht Miner.... 

Ein weiteres Argument wie wichtig Nodes sind, auch wenn sie keine Miner sind. Alles Argumente pro BTC und gegen BSV... 

 

Bearbeitet 3. Juni 2020 von fjvbit

[Jokin]

vor 8 Stunden schrieb DefinierMirCoin:

Wer hätte das gedacht, das tolle Lightning Network bringt weitere Sicherheitsprobleme mit sich. 

Dir ist schon bewusst, dass sich das Lightning-Network in der Beta-Phase befindet und sich viele Programmierer auf der Suche nach Schwachstellen und Sicherheitsrisiken befinden?

Es passierte nun genau das, was passieren musste um das Netzwerk weiterzuentwickeln.

Wenn ich das richtig lese, dann ist das nur eine theoretische Beschreibung eines Angriffs.

Ist ein Lightning-Node erstmal mit einem anderen verbunden, dann kommt da niemand mehr zwischen. Zumindest sehe ich gerade keine Möglichkeit wie das gehen soll.

Während bei LN Code in der Betaphase ausgiebig getestet wird, ist das bei BSV anders: Bei BSV wird der Code noch nichtmal in der Produktivphase getestet

(der Bug, den ich gefunden habe, ist immernoch drin)

 

Und es kommt noch besser!

https://github.com/bitcoin-sv/bitcoin-sv/releases/tag/v1.0.3

Schaut mal, was für ein Bug ca. 3 Monate nach Produktivsetzung des Genesisupdates gefixt wurde:

"Fix lost transactions under high load."

Ich brech zusammen  

Da hat also das unendlich skalierbare BSV-Netzwerk festgestellt, dass da unerwartete Grenzen sind, die mit der Rechenleistung der Nodes zu tun haben?

Wie dilettantisch.

Wer dann auch noch in einem BSV-Thread auf die Fehler anderer Projekte im Beta-Stadium zeigt und sich darüber amüsiert, möge doch bitte noch einmal in sich gehen ob er überhaupt irgendetwas technisches verstanden hat - das erscheint mir hier immer mehr als reine BSV-Propaganda-Show.

[PeWi]

9 hours ago, DefinierMirCoin said:

Zum Glück steht auch drin, was man dagegen tun kann:
Higher connectivity and the number of honest reachable nodes.  ==>  Hier musste ich wirklich lachen, in Anbetracht der letzten Diskussionen. Hörst du @PeWi , ein sicheres LN basiert auf honest Nodes   

Was ich bisher von LN mitbekommen habe, z.B. durch Christophs Artikel, spricht mich jetzt auch nicht so an. 😉

IMHO ist das ein (zu?) großer Komplexitätssprung mit vielen Randbedingungen, die den Einsatz noch weiter verkomplizieren.

[Flenst]

vor 15 Stunden schrieb DefinierMirCoin:

Ähm, es gibt nur einen freien Markt.
Und ja, er richtet sich nicht nach den Vorstellungen einiger weniger. Er entwickelt sich. Und wer da nicht "mit der Zeit mitgeht, der geht mit der Zeit" 😉

Wenn dann jemand geht ist das aber derjenige, der weniger Gewinn macht. Und das sind nicht die Miner, die die kleinen Blöcke minen.

Ich werde aber auch das Gefühl nicht los, dass das BSV Netzwerk an sich einen Klatsch weg hat. Warum?

Mempool hat genügend Transaktionen vorrätig, und ein und derselbe Pool mined mal einen etwas größeren Block, mal einen kleinen, dann wieder einen kleinen. Es wirkt absolut willkürlich. Und leer macht er den Mempool natürlich nicht. Darum gehts: https://imgur.com/qEiHbuN

Der gleiche Pool, willkürliche Blöcke. Das kann man auch bei anderen beobachten. Bleib also dabei, das BSV Netzwerk läuft, aber bei weitem nicht so rund wie man es hier verkauft.

[Flenst]

vor 9 Stunden schrieb DefinierMirCoin:

Zum Glück steht auch drin, was man dagegen tun kann:

 

Higher connectivity and the number of honest reachable nodes.  ==>  Hier musste ich wirklich lachen, in Anbetracht der letzten Diskussionen. Hörst du @PeWi , ein sicheres LN basiert auf honest Nodes   

Du propagierst weniger Nodes, sie schlagen mehr Nodes vor. Im Grunde sagen sie das, was hier auch gesagt wird: mehr Nodes = mehr honest Nodes = mehr Sicherheit.

vor 10 Stunden schrieb DefinierMirCoin:

Ja dann habe ich wohl den falschen Blockexplorer benutzt, da sind halt 2 Minuten Unterschied zu sehen. 
Wie auch immer, ihr weicht meiner Frage aus, was die 2 Sekunden mit der Blockgröße zu tun hat.

Wenn ein Block den Mempool leert, dann ist der Block kurz darauf sehr klein oder sogar leer. So logisch, so einfach. Naja, bei BSV wird der Mempool ja kaum geleert, vielleicht fehlts hier an Erfahrung

vor 10 Stunden schrieb Jokin:

Nachdem bei tocial und ANNE offenbar nix mehr passiert, gehen nun die Transaktionszahlen bei den Payment wieder hoch.

Selbstredend, dass das schon wieder künstlich angelegte Unsinnstransaktionen sind:

Sehr geil Aber man muss ja die Illusion aufrecht erhalten bei BSV seien die Transaktionszahlen höher als bei BTC

[Jokin]

 

vor 42 Minuten schrieb Flenst:

Wenn dann jemand geht ist das aber derjenige, der weniger Gewinn macht. Und das sind nicht die Miner, die die kleinen Blöcke minen.

Ich werde aber auch das Gefühl nicht los, dass das BSV Netzwerk an sich einen Klatsch weg hat. Warum?

Mempool hat genügend Transaktionen vorrätig, und ein und derselbe Pool mined mal einen etwas größeren Block, mal einen kleinen, dann wieder einen kleinen. Es wirkt absolut willkürlich. Und leer macht er den Mempool natürlich nicht. Darum gehts: https://imgur.com/qEiHbuN

Der gleiche Pool, willkürliche Blöcke. Das kann man auch bei anderen beobachten. Bleib also dabei, das BSV Netzwerk läuft, aber bei weitem nicht so rund wie man es hier verkauft.

Aber na klar hat das BSV-Netzwerk einen Klatsch weg.

Gern hier der Beweis:

https://bitcoinblocks.live

... da laufen die ganzen Transaktionen durch, die dieses Tool in der Blockchain sieht. Bzw. das Tool ist ja auch nur mit einem Node verbunden und greift sich dessen Daten ab. Derzeit sieht man wunderbar wie die Payment-Transaktionen da gespammt werden.

Ich benutze ganz gern diese vier Blockexplorer:
https://whatsonchain.com
https://blockchair.com
https://bsv.tokenview.com
https://bchsvexplorer.com

Diese Blockexplorer greifen auf unterschiedliche Nodes zu.

Eine gerade neu erschienene Transaktion bei "bitcoinblocks.live" dauert teilweise viele Minuten bis Stunden bis diese in allen Blockexplorern angezeigt werden.

 

Man stelle sich nun ein Gruppe von 300 Menschen vor, die als Gruppe nah beieinander steht. Nun gibt man einem Menschen eine Nachricht und wartet darauf bis jeder der 300 Menschen die Nachricht erhalten hat.

Diese 4 Blockexplorer sind "Stichproben" aus den 300 Menschen.

Meine Beobachtung bestätigt, dass das BSV-Netzwerk derart viele Transaktionen "hineingespamt" bekommt, dass es nicht in der Lage ist die Nachrichten durchzureichen.

Denn jeder Mensch dieser Gruppe muss möglichst gleichzeitig hören, überlegen ob das Gehörte korrekt und plausibel ist und weitersagen.

 

Es liegt auf der Hand, dass kürzere Nachrichten einfach weiterzugeben sind als wenn an einer Nachricht noch ein riesiges Datenpaket hängt - die wenigsten Menschen der Gruppe wollen sich die gesamte Nachricht inkl. Datenpaket anhören.

Technisch läuft das so ab:

Mensch 1: "Ey Du"
Mensch 2: "Ja?"
Mensch 1: "Ich hab die Transaktion xy - kennste die schon? die hat aber 200 MB."
Mensch 2: "Leck mich, ich kann in derselben Zeit 200.000 andere kurze Nachrichten hören"
Mensch 1: "Aber die Fee ist total hoch!"
Mensch 2: "Interessiert mich nicht, ich bin ein Node und kein Miner"
DefinierMir Coin: "Aber Nodes sind doch dasselbe wie Miner"
Jokin: "Nein, jedem Miner ist ein Node vorgeschaltet, der entscheidet welche Nachrichten angenommen werden und welche nicht, was der Node ablehnt, sieht der Miner nicht"

Exakt das passierte bei meinem Test im BSV-Testnet - keine Sau wollte meine 200-MB-Transaktion haben.

Ok, aber zurück zu den kleinen Transaktionen - je mehr gleichzeitig kommen, desto mehr ist das Netzwerk mit dem Verteilen der Nachrichten ausgelastet.

Mit jedem weiteren Netzwerkteilnehmer wird mehr gequatscht, denn jeder, der die Transaktion bereits hat, quatscht seine Nachbarn an mit "Ey Du" und "Ich hab die und die Transaktion, kennste die schon?" 

Wir erleben also direkt live, dass zu manchen Zeiten das Netzwerk "dicht" ist und die Transaktionen gar nicht schnell genug an alle Teilnehmer verteilt werden können. Und was die Miner nicht kennen, können sie auch nicht in Blöcke aufnehmen.

Daher: BSV skaliert nicht. Schlimmer: Durch Aufheben von Limitierungen verstopft sich BSV immer wieder selber.

Aber es gibt natürlich WorkArounds, die als Super-Innovation propagiert werden!

Workaround 1: 0-conf
Der erste Ansatz war, dass Transaktionen, die zwar bei den Nodes angekommen sind aber noch nciht in Blöcke gebaut wurden auch ohne Bestätigungen akzeptiert werden sollen - nice try, denn Transaktionen können dennoch verwaisen und nie bestätigt werden.

Damit ist aber noch nicht das Problem bearbeitet, dass es Transaktionen gar nicht schnell genug in die Blockchain schaffen, denn wie soll etwas per 0-conf akzeptiert werden, was nicht auf den Nodes sichtbar ist.
Dieses Problem wurde sichtbar als das Bezahlen im Shop trotz 0-conf nicht klappte, denn der Bezahlende hatte zwar den QR-Code gescannt und die Transaktion auf den Weg geschickt, aber der Merchant sah sie nie auf dem Node mit dem er verbunden ist.

Workaround 2: Merchand-API
Also muss nun der Händler selber die Transaktion in die Blockchain senden und das so oft bis sie irgendwann mal von einem Node angenommen wird.
Diese Entwicklung ist vollkommen logisch um das Versagen der BSV-Blockchain zu kaschieren.

 

Ich hoffe, das war auch für stille lesende Laien halbwegs nachvollziehbar?

 

Dass die BSV-Blockchain Schrott ist, sieht man auch daran, dass seitens BSV immer wieder die Negativpunkte von BTC aufgebracht ohne diese sachlich zu begründen.
Ich hoffe, es wurde deutlich, dass ich BSV nicht einfach nur blame sondern ganz klar mit Fakten das Vollversagen von BSV zu belegen.

 

 

 

 

[DefinierMirCoin]

vor 8 Stunden schrieb fjvbit:

Du hast LN immer noch nicht getestet? 

Richtig. Ich sehe keinen Mehrwert dain und bleibe lieber bei echter onchain Bitcoin-Technologie.

vor 2 Stunden schrieb Flenst:

Wenn ein Block den Mempool leert, dann ist der Block kurz darauf sehr klein oder sogar leer. So logisch, so einfach. Naja, bei BSV wird der Mempool ja kaum geleert, vielleicht fehlts hier an Erfahrung

Ja das hatte ich in der Tat vergessen, dass bei BTC nichts los ist, und dass ein MB Block gleich ALLE getätigten TX "aufbraucht".  Und nach einer Minute war nur 1 Transaktion im Mempool? Wow. Das bestätigt ja nochmal, dass BTC keine usability hat. 

Das gleiche ist übrigens heute wieder vorgekommen: https://www.blockchain.com/de/btc/block/00000000000000000001f8bdcf08f6ed511c958c65d47870bfed78ddc00cf82f
Scheint doch kein Einzelfall gewesen zu sein.

Wie auch immer, das erklärt jedenfalls nicht, warum der Miner nicht gewartet hat, bis mehrere TX vorhanden war, damit er seinen MB füllt und er mehr Profit macht.  @Jokin hat gesagt, das würden die BTC miner alle so tun. Offensichtlich ist das nicht der Fall.

[DefinierMirCoin]

You split? We bankrupt you    

https://store.bitcoin.com/
"Bitcoin.com Store will be shutting down on the 8th of June"

[Jokin]

 

 

 

 

 

 

Der Payment Bot hat innerhalb von 22 Stunden mal eben 220.000 Transaktionen rausgehauen:

https://blockchair.com/bitcoin-sv/address/1GUwVDGhewzYgSujuXP1ZmBmsKR8cfCQKZ

Das Ding transferiert die Coins immer nur an sich selbst  

Hier ist noch ein Payment Bot: https://blockchair.com/bitcoin-sv/address/1Lmq6jsc3bQKH9tkoA2qyJyNNewdhDdZr1

 

 

 

 

Bearbeitet 4. Juni 2020 von Jokin

[skibby]

Danke @Jokin, der beste Beitrag hier

[DefinierMirCoin]

vor einer Stunde schrieb Jokin:

Workaround 1: 0-conf
...
Damit ist aber noch nicht das Problem bearbeitet, dass es Transaktionen gar nicht schnell genug in die Blockchain schaffen, denn wie soll etwas per 0-conf akzeptiert werden, was nicht auf den Nodes sichtbar ist...

Seit wann sind 0-conf TX in der Blockchain?  Hast du Bitcoin verstanden?
Das "conf" steht für "Bestätigung". "0" bedeutet "keine". Die TX ist also im Mempool. Darin bleibt sie bis sie verarbeitet und bestätigt wird (1 conf) oder der (in der Praxis unwahrscheinliche) 14-Tage Timeout zuschlägt. 

An die stillen Leser hier, lasst euch nicht für Dumm verkaufen. Macht euch selbst schlau.
0-Conf funktioniert bei BCH/BSV gut, genauso wie es soll. Der Mempool ist Teil der FullNode-Miner, die alle eng miteinander verknüpft sind. Nur bei BTC kann man 0-conf nicht vertrauen, da dort eine TX im Nachgang manipuliert werden kann und die generelle Synchronisation im Mesh-Netzwerk aufgrund der vielen unnützen Nodes verlangsamt ist.

 

vor 1 Stunde schrieb Jokin:

Workaround 2: Merchand-API
Also muss nun der Händler selber die Transaktion in die Blockchain senden und das so oft bis sie irgendwann mal von einem Node angenommen wird.
Diese Entwicklung ist vollkommen logisch um das Versagen der BSV-Blockchain zu kaschieren.

Falsch. Die Merchant API ist eine evolutionäre Entwicklung im Bitcoin Ecosystem. Das ist eine Dienstleistung. Damit wird nichts kaschiert, sondern neue Möglichkeiten geschaffen.
Auch für andere Coins haben Wallet Anbieter soetwas im Programm.  Das ist eine Folge von Wettberwerb. Wie ich oben schon schrieb "wer nicht mit der Zeit geht, geht mit der Zeit".

 

[Jokin]

vor 12 Minuten schrieb DefinierMirCoin:

Seit wann sind 0-conf TX in der Blockchain?

 

Hat ja auch niemand so geschrieben. 😉 

vor 14 Minuten schrieb DefinierMirCoin:

Damit wird nichts kaschiert

Doch, ansonsten bräuchte das niemand.

 

[Flenst]

vor 8 Minuten schrieb DefinierMirCoin:

Seit wann sind 0-conf TX in der Blockchain?  Hast du Bitcoin verstanden?
Das "conf" steht für "Bestätigung". "0" bedeutet "keine". Die TX ist also im Mempool. Darin bleibt sie bis sie verarbeitet und bestätigt wird (1 conf) oder der (in der Praxis unwahrscheinliche) 14-Tage Timeout zuschlägt. 

An die stillen Leser hier, lasst euch nicht für Dumm verkaufen. Macht euch selbst schlau.
0-Conf funktioniert bei BCH/BSV gut, genauso wie es soll. Der Mempool ist Teil der FullNode-Miner, die alle eng miteinander verknüpft sind. Nur bei BTC kann man 0-conf nicht vertrauen, da dort eine TX im Nachgang manipuliert werden kann und die generelle Synchronisation im Mesh-Netzwerk aufgrund der vielen unnützen Nodes verlangsamt ist.

Hat er schon, du aber seinen Beitrag nicht. Er zeigt ganz eindeutig auf, dass die Nodes unterschiedliche Mempools haben. Und das ist das Problem: hat die Node die man für die Abfrage der 0-conf nutzt die Transaktion nichtmal im Mempool, dann geht auch 0-conf nicht.

Und gerade die Miner vedeutlichen dieses Problem. Miner haben Regeln, nach denen sie Transaktionen in einen Block packen. Das ist im Regelfall die Blockgröße, wenn das selbstgesetzte Limit des Miners erreicht ist, und dann noch die Fees. Fee zu niedrig, dann kommen sie garnicht rein. Ist die Fee höher, dann kommen sie eher in den Block. Und hier verdeutlicht es sich jetzt: es ist bei ein und denselben Minern zum Teil keine Regel zu erkennen. Blockgröße schwankt zwischen 300kB und 5MB (obwohl noch mehr im Mempool ist), am Fee-Limit liegt es auch nicht. Was hier also naheliegend ist: das Netzwerk ist aufgrund des Mangels an Nodes auf irgendeine Art fragmentiert, und das ist schlecht.

Und ja, jeder soll sich selbst eine Meinung bilden. Du zum Beispiel sagst in BTC ist die generelle Synchronisation aufgrund der vielen unnützen Nodes verlangsamt. Aber wirklich beobachten können wir das live bei BSV ohne die "unnützen Nodes". Schon komisch, oder?

[DefinierMirCoin]

Interessant, Ira Kleiman versucht den finalen Gerichtsprozess mit CSW im Juli zu umgehen. Das Gericht solle doch jetzt schon eine Vorentscheidung treffen und einfach bestätigen dass CSW ein Betrüger ist. Das wäre das Gegenteil von dem was er mit dem langjährigen Prozess bezweckt hat. Hat er etwa Angst vor dem Ausgang oder geht ihm nur das Geld aus?   

Mehr dazu: https://coingeek.com/ira-kleiman-accuses-craig-wright-of-defrauding-court-seeks-default-judgment/