Dann wird derjenige aber garantiert nicht zur Staatsanwaltschaft gehen und die Firma wird sich auch nicht bewegen. Auch die Beiträge hier sind dann zeitverschwendung, da ein Betrüger damit keinen Druck aufbauen kann.
|
|
|
Es fand kein Fremdzugriff statt wie er behauptet.
Das kannst Du gar nichts wissen, ansonsten wärst Du nämlich Mitarbeiter der Firma! Trotzdem wäre das Vorgehen der Firma im geschilderten Fall nicht in Orndung, daher auch hier schriftliche Mahnung (zwecks Nachweis, die Behörden stehen auf sowas), bei ausbleibender Reaktion gefolgt von einem Strafantrag. Und löst euch von einzelnen Personen, Vertragspartner/Schuldner ist die Firma und nicht deren Hot-Line Mitarbeiter.
|
|
|
There are so many different ways this UASF could fail catastrophically...
I'm waiting for the detailed analysis (minus the usual ad hominem) ... I don't think a detailed analysis is worth my time (and may be beyond my expertise)... it's a stupid idea ... I see, the "no one should ever have left the oceans" argument. q.e.d.
|
|
|
There are so many different ways this UASF could fail catastrophically...
I'm waiting for the detailed analysis (minus the usual ad hominem) ...
|
|
|
If core goes through with this user-driven soft fork, I think it will be the final end of their credibility, ...
Not if a change is user-driven.
|
|
|
Ich schulde auch den Poolbetreibern nichts und muss mich nicht von denen erpressen lassen!
Daher bin ich auch bezüglich der Änderung des Mining Algorithmus flexibel. Ein Algorithmus, der das UTXO Set und den Blockinhalt in jeder Runde nutzt wäre für das Pool-Mining völlig ungeeignet. Nebenbei sind dafür auch einfache ASIC Rechner und GPUs ungeeignet, was dem System erst mal wieder etwas Luft verschaffen würde.
Daher wäre es sinnvoll mit dem nächsten Hard-Fork auch den Mining Algorithmus zu ändern und so die erpresserischen Poolbetreiber loszuwerden.
|
|
|
Wie bereits gesagt, ich hätte nichts gegen einen Hard-Fork und bin flexibel bis 8 MB. Wenn sich die meisten Nutzer einig sind, haben die Core Entwickler keine Stimme mehr, da man diesen Hardfork auch ohne sie durchziehen kann. Ein paar Poolbetreiber werden das blockieren, aber auf die sollte man sowieso nicht hören - ihre Rolle im System ist eine andere!
Ich sehe allerdings auch, dass ich mit dieser Flexibilität nicht stellvertretend für alle Nutzer dastehe. Ich gehe davon aus, dass die ganzen Nutzer alter Software ihre Gründe haben, die alten Versionen einzusetzen.
Aus technischer Sicht ist es allerdings sinnvoll, mindestens gleichzeitig mit einer Blockerhöhung für einen lineare Verifikationsaufwand der Transaktionen zu sorgen. Wenn dann noch TM gelöst wird, ist es sicherlich auch kein Fehler.
|
|
|
At the end, money is a social thing - there is no value without peers. Everybody using the same system provides the maximum value. If this is impossible the better approach is to split the system. I'm fine with BU splitting the chain and following it's own way - without myself.
|
|
|
FYI, I'm fine with one blocksize increase up to a maximum of 8MB if segwit (or another linear transaction verification time method) is available and most of the community is supporting this change as well.
FYI, Bitcoin doesn't care about what most of the 'community' wants. It's only what most of the miners want that matters. In this case the nodes would not need to verify the blocks against the consensus rules. In reality all nodes have to verify and accept the blocks. Even if a majority of the miners create invalid blocks the other nodes will not accept these invalid blocks. Every node has to decide what is valid and what is invalid.
|
|
|
Absolut gesehen hat der Kurs gerade ca. den Wert einer ganzen INTC Aktie verloren. Dass es um knapp 3% geht und es über 200 mal soviele INTC Aktien wie BTC gibt, sind nachrangige Details.
|
|
|
FYI, I'm fine with one blocksize increase up to a maximum of 8MB if segwit (or another linear transaction verification time method) is available and most of the community is supporting this change as well.
|
|
|
Ich mache gar nicht mit, weil ich das für sinnlos halte. Sollte BU nach XT/Classic scheitern, dann werden wir bald darauf den nächsten "tolle" Hard-Fork präsentiert bekommen und dieselben Leute werden wieder die versuchen, die weitere Entwicklung zu blockieren.
Es ist relativ klar, dass aktuell >50% der Knoten mit segwit umgehen können und >99% der Knoten auch nach dem Soft-Fork ohne Veränderung mit dem System arbeiten können. Dagegen sind <10% der Knoten in der Lage mit einem Hard-Fork umzugehen. Diese Nutzer alle zum einem terminierten Update (Hard-Fork) zu zwingen halte ich für groben Unfug. Das Ganze kann nur den Zweck haben, die weitere Entwicklung zu blockieren.
Revolution (ein Hard-Fork) funktioniert mit keinem grösseren funktionierenden technischen System. Evolution (ein Soft-Fork) ist dagegen tägliche Praxis. Nicht Umsonst gibt es bis heute keine revolutionäre Umstellung von IPv4 auf IPv6. Kein grösseres Betriebssystem bekommt eine revolutionäre Umstellung der Schnittstelle hin, nach der sämtliche Software neu angepasst werden muss. Bei Geld sehe ich revolutionäre Änderungen noch kritischer. Trotzdem hätte ich persönlich kein Problem mit einer Änderung der Blockgrösse (bis 8MB) - gehöre damit aber vermutlich zur kleineren Gruppe unter den Bitcoin Nutzern.
|
|
|
As a first step against hostile pool operators blocking the evolution of the system, I would not start with dropping their blocks but I will not relay their new blocks anymore. If a large number of nodes do not relay those blocking blocks, there will be a chance that a good block with the same height is found. In this case the blocking block is dropped and the good block is the new head of the chain. If a good block is built on top of a blocking block the blocking block is accepted as well. If a lot of nodes use such a rule it will lead to bad luck for hostile pool operators.
I am curious what method you are using to accomplish this. By patching my client to not relay any blocks without my preferred BIP9 flag(s) and by giving more weight to chains with a head block with these BIP9 flag(s) set. It makes sense to make the feature configurable because if BU will follow the XT/Classic road, these guys will show up with the next "solution" and try to block further development of the system. Those guys will never stop bullying the Bitcoin community.
|
|
|
Das wäre dann PoS (Proof of Stake). Damit gibt es dann aber wieder andere Probleme. Ist eben nicht alles schwarz oder weiss.
Mal abwarten, wie sich die Sache entwickelt.
|
|
|
Ein "feindlicher" Fork würde zu einem selbst für Bitcoin-Verhältnisse beispiellosen Absturz führen!
Was komisch wäre. Warum sollte ein Fork - der ja von den Nutzern getragen werden muss - zu einem Kurssturz (= Vertrauensverlust) durch eben diese Nutzer führen?! Vermutlich gehe ich zu rational an die Sache heran.
|
|
|
ONE HASH ONE VOTE + alle Knoten verifizieren das Ergebnis.
So ist es korrekt, nennt sich dann Konsens.
|
|
|
will keiner so richtig RESET drücken? ich würde so gerne so um die 1100 wieder einkaufen Langsam wird es bescheiden? Vor kurzem wollten die Leute hier noch für 600-800 Einkaufen. mezzo die Zeiten ändern sich ständig, deswegen wird immer schnell angepasst. Im sinne Heute schnell REIN Morgen wieder RAUS = 1k bis 2k Fiat macht auch glücklich HA, Ha, ha Den letzten Satz kann ich nicht unterschreiben. Fiat-Geld schafft (mir) nur Probleme und bringt (mir) Ärger ein. Ganz besonders wenn es manche Gläubiger, die es rechtlich nehmen müssen, nicht aktzeptieren wollen. Sieht aber sowieso wieder mal nicht so aus, als ob der Versuch zu einem echten Abwärtstrend führen würde.
|
|
|
Edit: Betrug ist übrigens kein schweres Vergehen im Sinne der Anzeigepflicht von Straftaten. Das wäre eher sowas wie Mord oder Landesverrat.
Immerhin ist Betrug ein Offizialdelikt. Ist aber egal. Niemand hindert die OP daran, eine Mahnung zu schicken und, falls diese ignoriert wird oder nicht erwartungsgemäss ausfällt, einen Strafantrag zu stellen. Genau das wäre meine Vorgehensweise, wenn eine Firma mich um meine Ansprüche betrügen möchte. Im Forum kann man den weiteren Verlauf öffentlich dokumentieren, aber eine primäre Problemlösung wird es hier nach der aktuellen Informationslage nicht geben.
|
|
|
|