Author

Topic: Eine Idee, die es wert wäre zu realisieren. (Read 3290 times)

newbie
Activity: 42
Merit: 0
November 10, 2013, 10:45:53 AM
#70
Ich hab jetzt nicht den ganzen Thread gelesen, aber weiss jetzt irgendjemand was die Idee ist?
Ausser das sie genial ist..

Es gibt da einen guten Thread im Bitcointalk-Forum (find ihn grad nicht) in dem steht das wenn man die Idee nicht veröffentlichen will weil man angst hat das andere sie stehlen könnten und das ganze besser machen könnten man sowieso der Falsche für die Umsetzung ist. Auch wenn du dann ein paar Monate vorsprung hättest, bringt dir nicht viel wenns die anderen professioneller machen.

Na das ist aber wohl nicht immer so.

Quote
Update: Please register at https://www.hostedredmine.com/account/register and tell me (better as a private message) the username or your real name so I can add you to the members list of the project management. Then you can access the first document in the project which tells about the idea in some detail (about 7 kB text).
sr. member
Activity: 298
Merit: 275
Bitcoin Association Switzerland
November 10, 2013, 08:23:29 AM
#69
Ich hab jetzt nicht den ganzen Thread gelesen, aber weiss jetzt irgendjemand was die Idee ist?
Ausser das sie genial ist..

Es gibt da einen guten Thread im Bitcointalk-Forum (find ihn grad nicht) in dem steht das wenn man die Idee nicht veröffentlichen will weil man angst hat das andere sie stehlen könnten und das ganze besser machen könnten man sowieso der Falsche für die Umsetzung ist. Auch wenn du dann ein paar Monate vorsprung hättest, bringt dir nicht viel wenns die anderen professioneller machen.
newbie
Activity: 42
Merit: 0
November 10, 2013, 05:33:39 AM
#68
Wer Kontrolle über den Server der "sende x BTC an Y" an den "Unterschreiber" schickt hat, der kann auch die Einmalpasswörter auslesen und ein korrektes Passwort mitsenden.
Ok, stimmt.


Irgendwann muss so ein Teil in deinem System existieren, wenn es automatisch ablaufen soll. Da ich mich sicher nicht auf irgendwelchen australischen Cloudservices für eine 7 kB Textdatei anmelde, wird es wohl dabei bleiben, dass mir deine Idee ein Mysterium ist.

Das ist nicht mein Problem, dann willst du nicht dabei sein. Redmine ist eine Web-Software fürs Projektmanagement, die mir hier jemand empfohlen hat. Hatte Probleme bei der Installation von Ruby on Rails. Da fehlte wohl was als ich die Software ausführen wollte... deswegen dieser Drittservice.
Ich melde mich fast täglich bei irgendwelchen Seiten an.
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 07:45:47 PM
#67
Quote
Ihr würdest euch wundern was auf Börsensystemen und professionellen Transaktionssystemen im Backend läuft.
Weiss ich und du ja scheinbar auch, insofern verwundert mich deine Einstellung *die anderen machen es ja auch so*.

Weil die Komponenten und Sprachwahl praktisch nie ausschlaggebend für die Sicherheit des Systems ist. Es sind immer Architekturprobleme, Designprobleme und einfache Implementierungfehler. Bei letzterem ist der Fehler Nummer 1 etwas selber zu machen, was die qualitativ ordentliche Standardlösung schon lange gelöst hat. Bei jedem zweiten Problem stolpere ich über Reste des NIH (Not Invented Here) Syndrom, sei es bei Protokollen, Cryptolösungen oder Standardbibliotheken.

Quote
Aus der Implementierungssicht könnte (!= muss) das Edit: quelloffene Script von der Security her sogar die bessere Lösung sein als ein compiliertes Programm oder ein Angestellter.
Das muss DU mir nun mal Erklären, vielleicht mit folgender Analogie.
Welchen Vorteil hast es einem Einbrecher (Hacker) nachdem er die Sicherheitsvorkehrungen deines Hauses (Server)
überwunden hat, den kompletten Grundriss des Hauses und damit die Wege und Lage deiner Wertsachen (DB/Wallet)
offen auf den Küchentisch zu legen (Script), anstatt diesen in einem versteckten Safe zu Deponieren (Kompillat)?
Ganz besonders, wenn wir davon ausgehen würden, dass der Einbrecher ohne Grundriss nur das Bild deiner
freundlichen Schwiegermutter in Öl über dem Kamin mitnehmen könnte, anstatt deiner echten Wertsachen?  Grin

Security by Obscurity ist keine Sicherheit. Wenn der Einbrecher an den Sicherheitsmechanismen vorbeigekommen ist, muss man damit rechnen, dass er nimmt was er bekommt. Ein bischen Obscurity durch den Compiler ist dann kaum noch relevant. Ziel muss sein, dass ein Einbrecher nicht unbemerkt ins System kommt. Wenn erst mal ein Enbruch im System war - vor allem wenn dann auch noch unbekannt ist ob es eine Priviledge Escalation gab - ist das System sowieso kompromitiert. Dann kann bis zum SMM Handler jeder mögliche Dreck im System stecken und alle Daten sind als kontaminiert zu betrachten. Die einzige Reaktion darauf kann sein, das System zu löschen und alle Schlüssel zu ersetzen. Und zwar ohne Ausnahme ALLE!

Ein compilierte Code ändert nichts daran an der notwendigen Reaktion. Sich darauf zu verlassen, dass der Angreifer zu blöd war compilierten Code zu verstehn oder zu infiltrieren ist blauäugig.
full member
Activity: 120
Merit: 100
November 09, 2013, 07:03:57 PM
#66
Abschliessend zu diesem Thema von meiner Seite:

@amunet
Nur zum Verständnis, mir geht es hier überhaupt nicht darum dir Vorzuschreiben wie du dein Projekt
Entwerfen sollst. Im Gegenteil, ich finde es gut Ideen zu haben und vor allem diese dann auch
umzusetzen. Wenn schon brauchbarer Code vorliegt verwerte diesen und starte dein Projekt.
Wenn es gut läuft, kanst du immmer noch Entscheiden, ob zusätzliche Sicherheit nötig ist.
Zumindest hast du jetzt schon ein paar Ideen was man machen könnte. Verzichte auf zu komplexe
Layer-Schichtung, da jeder Layer die Anzahl möglicher Exploits auf deinem Applikations-Stack
multipliziert. Keep it simple and fast. Wo weniger dran ist, kann auch weniger kaputt gehen ;-)

@mezzomix

Quote
Ihr würdest euch wundern was auf Börsensystemen und professionellen Transaktionssystemen im Backend läuft.

Weiss ich und du ja scheinbar auch, insofern verwundert mich deine Einstellung *die anderen machen es ja auch so*.

Quote
Aus der Implementierungssicht könnte (!= muss) das Edit: quelloffene Script von der Security her sogar die bessere Lösung sein als ein compiliertes Programm oder ein Angestellter.

Das muss DU mir nun mal Erklären, vielleicht mit folgender Analogie.
Welchen Vorteil hast es einem Einbrecher (Hacker) nachdem er die Sicherheitsvorkehrungen deines Hauses (Server)
überwunden hat, den kompletten Grundriss des Hauses und damit die Wege und Lage deiner Wertsachen (DB/Wallet)
offen auf den Küchentisch zu legen (Script), anstatt diesen in einem versteckten Safe zu Deponieren (Kompillat)?
Ganz besonders, wenn wir davon ausgehen würden, dass der Einbrecher ohne Grundriss nur das Bild deiner
freundlichen Schwiegermutter in Öl über dem Kamin mitnehmen könnte, anstatt deiner echten Wertsachen?  Grin
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 05:07:27 PM
#65
Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.
(...)
Simples Beispiel (PHP/MySQL):
Sobald Shell Zugang existiert (muss noch nicht mal root sein), reichen ein paar
Greps aus, alle DB Connectoren aus den Confs oder direkt aus den Sourcen auszulesen.  
(...) ist deine Schwachstelle IMMER dein Script, da offen, tracebar und unter Kommunikationszwang zur DB.
Die Dateien mit Zugangsdaten als auch die Scripte könnte man verschlüsseln und das zugehörige Passphrase auf mehrere Dateien (teilweise ebenso verschlüsselt) verteilen bzw. so dass ein Angreifer dies nicht ohne großen Aufwand heraus findet.

Ich meine, man sollte sich nicht so auf diese Scripte versteifen. Ihr würdest euch wundern was auf Börsensystemen und professionellen Transaktionssystemen im Backend läuft. Es gibt einen Unterschied zwischen Interface und Implementierung. Wenn ich eine Anfrage X an einen Service sende und er Antwortet mit einer Aktion Y, dann ist es für die Sicherheit aus Architektursicht unerheblich ob dahinter ein compiliertes Programm, ein Script oder ein Angestellter sitzt. Aus der Implementierungssicht könnte (!= muss) das Script von der Security her sogar die bessere Lösung sein als ein compiliertes Programm oder ein Angestellter.
legendary
Activity: 2618
Merit: 1006
November 09, 2013, 03:19:26 PM
#64
Wer Kontrolle über den Server der "sende x BTC an Y" an den "Unterschreiber" schickt hat, der kann auch die Einmalpasswörter auslesen und ein korrektes Passwort mitsenden.

Irgendwann muss so ein Teil in deinem System existieren, wenn es automatisch ablaufen soll. Da ich mich sicher nicht auf irgendwelchen australischen Cloudservices für eine 7 kB Textdatei anmelde, wird es wohl dabei bleiben, dass mir deine Idee ein Mysterium ist.
newbie
Activity: 42
Merit: 0
November 09, 2013, 02:34:21 PM
#63
Irgendwo sitzt in dem System (sofern es automatisiert ist) ein kleines Kästchen, das einfach nur "3 BTC an 12345abc" bekommt und das dann unterschriebt und absendet. Ob jetzt jemand das Kästchen oder die Stelle kompromittiert, die diese Anweisungen gibt, ist wohl egal. Klar kann man z.B. den Riegel manuell vorschieben (z.B. "alles über 1 BTC in 24 Stunden erstmal NICHT unterschreiben, das schau ich mir lieber erstmal selber an!"), aber solange das automatisch laufen soll, hast du einfach 0 Chance.
Diesen Angriffsvektor könnte man mit einer Authentifikation durch eine Einmal-Passwort-Liste beseitigen.

Irgendwie ist das Ganze hier aber ziemlich spezifisch und Off-Topic geworden. Roll Eyes
Ich finde die Diskussion trägt bereits zu dem Projekt bei.

Da es zu der Idee anscheinend ja nix neues/genaueres gibt und sie erst enthüllt werden soll, wenn da auch wirklich was dazu existiert fürchte ich, dass es ab hier eh nur bergab gehen kann. Viel Erfolg an den TE, vielleicht schafft man es ja wirklich auch mit solchen vagen Umschreibungen schon mal Leute zu interessieren, die das auch machen?

Ich verweise nochmal auf das Update im Anfangspost, da ich die Idee auf Englisch genauer erläuterte und dieses Dokument nach einer Einladung lesbar ist.
legendary
Activity: 2618
Merit: 1006
November 09, 2013, 01:55:40 PM
#62
Irgendwo sitzt in dem System (sofern es automatisiert ist) ein kleines Kästchen, das einfach nur "3 BTC an 12345abc" bekommt und das dann unterschriebt und absendet. Ob jetzt jemand das Kästchen oder die Stelle kompromittiert, die diese Anweisungen gibt, ist wohl egal. Klar kann man z.B. den Riegel manuell vorschieben (z.B. "alles über 1 BTC in 24 Stunden erstmal NICHT unterschreiben, das schau ich mir lieber erstmal selber an!"), aber solange das automatisch laufen soll, hast du einfach 0 Chance.

Irgendwie ist das Ganze hier aber ziemlich spezifisch und Off-Topic geworden. Roll Eyes

Da es zu der Idee anscheinend ja nix neues/genaueres gibt und sie erst enthüllt werden soll, wenn da auch wirklich was dazu existiert fürchte ich, dass es ab hier eh nur bergab gehen kann. Viel Erfolg an den TE, vielleicht schafft man es ja wirklich auch mit solchen vagen Umschreibungen schon mal Leute zu interessieren, die das auch machen?
newbie
Activity: 42
Merit: 0
November 09, 2013, 12:09:06 PM
#61
P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Vieleicht "Es"? SCNR  Grin

Das ist korrekt. Ich bin eine Transe, aber lass mich doch gerne mit "sie"/Frau anreden. Doch relevant ist das nicht gerade hier.
Ich bin nur eine Person, manchmal zwiespältig, also vielleicht doch mehrere? lol.


Zu deiner Frage:
Ein Service, der u.U Werte in Mio. Höhe vorhält, sollte so konstruiert sein, daß
selbst ein unauthorisierter Shell Zugriff keinerlei Coin-Entwendung ermöglicht
sondern maximal eine Störung verursachen kann.
Ja ein zweites inputs.io sollte nicht passieren Cheesy


Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.
(...)
Simples Beispiel (PHP/MySQL):
Sobald Shell Zugang existiert (muss noch nicht mal root sein), reichen ein paar
Greps aus, alle DB Connectoren aus den Confs oder direkt aus den Sourcen auszulesen.  
(...) ist deine Schwachstelle IMMER dein Script, da offen, tracebar und unter Kommunikationszwang zur DB.
Die Dateien mit Zugangsdaten als auch die Scripte könnte man verschlüsseln und das zugehörige Passphrase auf mehrere Dateien (teilweise ebenso verschlüsselt) verteilen bzw. so dass ein Angreifer dies nicht ohne großen Aufwand heraus findet.

Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.
Beispiel (C/NoSQL-Lib oder pure libmysql, falls SQL Syntax sein muss):
Als DB-Backend kommt eine Low-Level NoSQL-Lib in Frage, idealerweise ohne TCP Stack
(Min. Latenz), falls TCP zwingend erforderlich ist kommt eine C-Lib in Frage, die Request
aus den ebenfalls kompilierten CGI's abarbeitet. ALLE Zugangsdaten und Cluster-Adressen
sind in der Lib statisch einkompiliert. DB-Verschlüsselung erfolgt durch die Lib NICHT
File- Bzw. OS Basiert, sondern per DATENSATZ. Passt sehr gut zu dem Dokumentenorientierten
Ansatz der DB. Was findet ein Angreifer mit Shell-Zugriff jetzt vor?
Simpel gesagt 3 Dateien. Eine DAT (DB) eine LIB (DB-Cluster-Connector) und eine EXE (CGI).
Selbst mit den derzeit besten Decompilern ist da wenig - innerhab des Zeitfensters -
zu machen. Der Angreifer kann weder auf die DB Zugreifen bzw. Auslesen, noch brauchbare
Rückschlüsse auf die Ablauflogik oder Cluster-Topologie ableiten um weitere Schwachstellen
oder gar das Cold-Wallet im Cluster zu Identifizieren.

Ja gut. Hm. Dafür bräuchte man eine etwas andere Art von Programmierer als einfach fürs Web.
Wäre allerdings schon weitaus solider als Interpreter.. wenn sich genug Mitwirkende dazu finden, würde ich das durchaus vorziehen. Zumindest für die sicherheitsrelevanten Teile.




Quote
Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.
(...)
Du kannst es Drehen wie du willst und Layer über Layer einsetzen um die gefühlte Sicherheit
zu verbessern aber sobald die den Trigger auslösende Schnittstelle (hier Das Web) offen ist
(Scripts) hast du mit allen nachfolgenden Sicherheitsmaßnahmen zwangsläufig verloren.
Ist doch auch klar, wenn der Auszahlauslöser im Web logischerweise bis auf deinen TAS einwirken
muss um eine Auszahlung zu veranlassen. Wenn diese Auszahllogik offen liegt, ist das System Kaputt,
egal wieviel hinten dranhängt.
Und genau darum gehts, diese Logik als offenes Script auf dem Server zu *Lagern* ist das Problem.

Ja moment.. Man kann doch von Webserver zu Server 1 eine Auszahlungsanweisung samt Bitcoin Adresse schicken usw. - Dann leitet Server 1 diese Anweisung an Server 2 weiter - hier hat es mit dem Webserver nichts mehr zu tun also steht auch in keinem Script auf dem Webserver irgendwelche Logik dazu. Und so weiter.
full member
Activity: 120
Merit: 100
November 09, 2013, 11:18:01 AM
#60
Quote
Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.

Transaktionsserver können ohne Event NIX machen. Der originäre Trigger kommt IMMER aus dem Netz.
Handlungsisolation gibt es nicht. Oder woher hat der TAS die Information und Daten eine Auszahlung zu veranlassen?
Maschinelle Intuition?  Grin

Du kannst es Drehen wie du willst und Layer über Layer einsetzen um die gefühlte Sicherheit
zu verbessern aber sobald die den Trigger auslösende Schnittstelle (hier Das Web) offen ist
(Scripts) hast du mit allen nachfolgenden Sicherheitsmaßnahmen zwangsläufig verloren.
Ist doch auch klar, wenn der Auszahlauslöser im Web logischerweise bis auf deinen TAS einwirken
muss um eine Auszahlung zu veranlassen. Wenn diese Auszahllogik offen liegt, ist das System Kaputt,
egal wieviel hinten dranhängt.
Und genau darum gehts, diese Logik als offenes Script auf dem Server zu *Lagern* ist das Problem.

ps: Es sei denn, du kannst dich an den eigenen Haaren aus dem Brunnen ziehen.
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 11:12:55 AM
#59
Quote
CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben.
Da kommst du nicht drumherum, egal wieviel Layer du dazwischen Schaltest. Letztendlich verarbeitest du Anfragen aus dem Web und
damit hast du eine bestehende Reaction-Chain.

Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.
full member
Activity: 120
Merit: 100
November 09, 2013, 11:03:13 AM
#58
Quote
Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

Wird schon gemacht, grössere Auszahlungen, die aus dem Cold-Wallet kommen werden nur in einem zugelassenen, vom CW-Server definierten Zeitfenster
ausgeführt. Anfragen ausserhalb des Zeitfensters werden vom System verworfen bzw. gar nicht erst beantwortet, da der Port
geschlossen bleibt.
full member
Activity: 120
Merit: 100
November 09, 2013, 10:59:35 AM
#57
Quote
CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben.

Da kommst du nicht drumherum, egal wieviel Layer du dazwischen Schaltest. Letztendlich verarbeitest du Anfragen aus dem Web und
damit hast du eine bestehende Reaction-Chain.

Quote
Mit welcher Technik die Schnittstelle betrieben wird (Scriptsprache, kompilierter Code) halte ich nicht für ausschlaggebend.

Falsch, wie oben beschrieben. Genau das macht den Unterschied. Bei Script bist du deine Coins los. Kompiliert nicht.
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 10:52:27 AM
#56
Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

Weiss gar nicht ob ich das schon irgendwo geschrieben hatte: Zumindest bei einem neu eingeführten System würde ich mindestens in der Anfangszeit die Auszahlungsfunktion des System mit nachgeschalteter manueller Kontrolle laufen lassen.

Zwischen Transaktionsserver und einem späteren Auszahlungsserver lässt sich dann mit den entsprechenden Erfahrungswerten auch wunderbar ein Test schalten, der typische Auszahlungsmuster überwacht und die Auszahlungsfunktion trennt bzw. nur noch manuelle Prüfung zulässt, sobald eine Abeichung vom bekannten Muster auftritt.

Nebenbei wäre ein Penetration Test auf einem parallel dazu laufenden identichen Dummy System nicht falsch.
hero member
Activity: 533
Merit: 539
November 09, 2013, 10:33:28 AM
#55
P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Vieleicht "Es"? SCNR  Grin

Geht mir ja gar nicht ums Geschlecht, sondern eher ob "Sie" schon Mehrere sind.
legendary
Activity: 2618
Merit: 1006
November 09, 2013, 10:33:01 AM
#54
Irgendwer ist immer root, ohne Vertrauen geht gar nichts wenn du nicht Bitcoins verwendest sondern IOUs (also Schuldversprechen). Sobald jemand in deinen Dienst was einzahlt, hat derjenige keine Bitcoins, nur mehr dein Verprechen, dass du sie irgendwann irgendwie zurückzahlst.

Einzahlungen kann man ganz einfach in der Blockchain überprüfen, dazu muss man nur die benutzten Adressen kennen, sonst gar nix.
Auszahlungen brauchen auch quasi keinen Netzwerktraffic (ein paar 100 Bytes für die Transaktion ins Bitcoinnetz) - aber irgendwo muss eine Maschine stehen, die Zugriff auf die Keys zu den Einzahlungsadressen hat. Quasi jeder Hack wurde dadurch ermöglicht, dass jemand Zugriff auf den Server erlangt hatte, der Auszahlungen ermöglicht.

Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 10:30:53 AM
#53
P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Vieleicht "Es"? SCNR  Grin
hero member
Activity: 533
Merit: 539
November 09, 2013, 10:28:17 AM
#52
Möchtest du nicht den Titel deines Threads auf einen seriöser klingenden Titel ändern.
Würde deutlich mehr Aufmerksamkeit darauf ziehen, denn so schreckt es potentielle Mitstreiter ab, bevor sie den Thread öffnen.

zB. "Eine Idee, die es wert wäre zu realisieren." oder "Habe eine Idee mit hohem Potential, suche Mitstreiter." etc.

P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 10:18:55 AM
#51
Ein Server im Wohnzimmer? Sicher? Sogar sehr! Ausfallsicher/hochverfügbar? Das wohl schon weit weniger...

Für einen Transaktionsserver bei dem richtig Geld im Spiel ist, kann ich mich mit dem Wohnzimmer irgendwie nicht so recht anfreunden. Ein überwachtest Rechenzentrum/Bürogebäude wäre da schon schöner - vor allem wenn die Zugangskontrolle mit der Notabschaltung des Systems gekoppelt wird.

Ein Service, der u.U Werte in Mio. Höhe vorhält, sollte so konstruiert sein, daß
selbst ein unauthorisierter Shell Zugriff keinerlei Coin-Entwendung ermöglicht
sondern maximal eine Störung verursachen kann.
Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.

Ein unbemerkter root Access ist auch für compilierten Code fatal. Wird das eindringen bemerkt ist sowieso speicherlöschen und Notabschaltung angesagt.

Bevor ich das gesammte System selber codiere und was weiss ich wie viele Fehler einbaue, setze ich hier lieber auf Standardlösungen kombiniert mit angepassten Überwachungs- und Sicherungsmechanismen.

Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.

CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben. Mit welcher Technik die Schnittstelle betrieben wird (Scriptsprache, kompilierter Code) halte ich nicht für ausschlaggebend.

Ein bischen sorge macht mir bei diesen Systemen das Betriebssystem. Auch hier ist eine eigene Implementierung meistens nicht realistisch. Wenn schon der Layer 2 Treiber Lücken hat, ist die restliche Absicherung auf Sand gebaut. In kritischen Projekten setzen wir dafür externe Überwachung ein. Macht die Sache aber nicht kostengünstiger.
full member
Activity: 120
Merit: 100
November 09, 2013, 09:48:14 AM
#50

Die Frage ist nicht ob man was von der Stange nehmen kann, sondern sollte.
Desweiteren habe ich ursprünglich die Nutzung von Interpreter in Frage gestellt
und alle von dir aufgezeigten *Härtungsversuche* sind sowieso selbstverständlich.

Zu deiner Frage:
Ein Service, der u.U Werte in Mio. Höhe vorhält, sollte so konstruiert sein, daß
selbst ein unauthorisierter Shell Zugriff keinerlei Coin-Entwendung ermöglicht
sondern maximal eine Störung verursachen kann.
Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.

Simples Beispiel (PHP/MySQL):
Sobald Shell Zugang existiert (muss noch nicht mal root sein), reichen ein paar
Greps aus, alle DB Connectoren aus den Confs oder direkt aus den Sourcen auszulesen.
Suchen muss man auch nicht lange, ist ja alles *Standard*, da weiss man was man hat.
Dieses Problem haben grundsätzliche alle Interpreter, sei es PHP/Python/Perl oder
eben auch Node. Gerne wird bei MySQL auch der TCP Stack auf Localhost gebindet um
die Kiste nach aussen Unsichtbar zu machen. Mit einer offenen Shell hat sich das
dann auch noch erledigt, Attacken können von der Shell aus Lokal ausgeführt werden,
wobei wahrscheinlich noch nicht mal nötig, da die Zugänge schon ausgelesen sind.
Zur Not werden die Scripte einfach *um nötige Funktionen erweitert*.
Dazu kommt noch, dass die gesamte Cluster Topologie ebenso per Source-Tracking
zu erfassen ist. Deine Scripte müssen ja mit dem Cluster kommunizieren, demnach
liegen zwangsläufig auch die Cluster-Adressen im Script bzw. in den Conf Files.
Kondensiert heisst das, sobald du Interpreter einsetzt kann ein Angreifer nach
Shell Zugang deine GESAMTE Ablauflogik, Connectoren-Zugänge und Cluster-Adressen
auslesen. Selbst wenn du zusätzliche Layer schaltest, ist deine Schwachstelle
IMMER dein Script, da offen, tracebar und unter Kommunikationszwang zur DB.

Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.
Beispiel (C/NoSQL-Lib oder pure libmysql, falls SQL Syntax sein muss):
Als DB-Backend kommt eine Low-Level NoSQL-Lib in Frage, idealerweise ohne TCP Stack
(Min. Latenz), falls TCP zwingend erforderlich ist kommt eine C-Lib in Frage, die Request
aus den ebenfalls kompilierten CGI's abarbeitet. ALLE Zugangsdaten und Cluster-Adressen
sind in der Lib statisch einkompiliert. DB-Verschlüsselung erfolgt durch die Lib NICHT
File- Bzw. OS Basiert, sondern per DATENSATZ. Passt sehr gut zu dem Dokumentenorientierten
Ansatz der DB. Was findet ein Angreifer mit Shell-Zugriff jetzt vor?
Simpel gesagt 3 Dateien. Eine DAT (DB) eine LIB (DB-Cluster-Connector) und eine EXE (CGI).
Selbst mit den derzeit besten Decompilern ist da wenig - innerhab des Zeitfensters -
zu machen. Der Angreifer kann weder auf die DB Zugreifen bzw. Auslesen, noch brauchbare
Rückschlüsse auf die Ablauflogik oder Cluster-Topologie ableiten um weitere Schwachstellen
oder gar das Cold-Wallet im Cluster zu Identifizieren.

Die höhere Startup-Latenz der kompilierten CGI's wird durch den direkten DB-Zugang
egalisiert. Der dabei eingekaufte Sicherheitsvorteil erhöht den Aufwand das System
zu Hacken enorm. Natürlich kann ein Angreifer gefrustet z.B. die DB Löschen aber
der Backup/Reinkarnationserver ersetzt die aus dem Sharding Umgehend (s. Minix/Microkernel)
Diesen Aufwand würde ich mir nicht für einen PopelShop machen aber für Finanzorientierte
Server bei denen es evtl. um Millionen geht mit Sicherheit und das mindestens.
newbie
Activity: 42
Merit: 0
November 09, 2013, 09:43:34 AM
#49
Ein Server im Wohnzimmer? Sicher? Sogar sehr! Ausfallsicher/hochverfügbar? Das wohl schon weit weniger...
Was ist denn daran sicher, wenn der, bei dem der Server steht zu jeder Zeit dran kann und aus praktischen Gründen wohl auch das Root-Passwort kennt. Selbst ohne das Passwort zu kennen könnte er darauf zugreifen.

Es reicht ja schon ein RaspberryPi um Auszahlungen (das ist das einzige, das wirklich ein Hotwallet und damit private keys braucht) zu ermöglichen.
Man sollte aber auch Einzahlungen ermöglichen Smiley

Ich würde sogar behaupten, dass man für Auszahlungen usw. nicht mal eine Standleitung braucht, sondern auch 32 MBit/s down bzw. ein paar Mbit up genügen würden. Dann dauern Auszahlungsphasen eben ein wenig länger. Das wäre aber nicht so dass man wie beim Webserver viele User zur gleichen Zeit bedienen können müsste.

Ansonsten aber denke ich spricht gar nichts dagegen dass man einen Transaktionsserver online hat. Vielleicht bei nem anderen Provider als der eigentliche Service. Wer mit Zugang zum Server sollte denn wissen, dass es sich um einen Bitcoins-Transaktionsserver für Dienst X handelt, usw!? Hier sehe ich bei "Server im Wohnzimmer" doch ein höheres Sicherheitsrisiko.
legendary
Activity: 2618
Merit: 1006
November 09, 2013, 09:15:52 AM
#48
Ein Server im Wohnzimmer? Sicher? Sogar sehr! Ausfallsicher/hochverfügbar? Das wohl schon weit weniger...

Es reicht ja schon ein RaspberryPi um Auszahlungen (das ist das einzige, das wirklich ein Hotwallet und damit private keys braucht) zu ermöglichen.
newbie
Activity: 42
Merit: 0
November 09, 2013, 08:02:36 AM
#47
Wenn wir über Finaztransaktionsserver reden ...

dann ist noch die Frage, ob das Projekt genug Geld einbringt um eine (mehrere? Verfügbarkeitsanforderungen?) Standleitung zu finanzieren. Dann wäre es eine Option, den Transaktionsserver lokal zu halten. Damit wäre der einzige Zugang ins Netz die Transaktionsschnittstelle zu dem(den) dedizierten Prozessserver(n). Damit lässt sich eine sehr gute Absicherung realisieren. Da das Protokoll sehr effizient gehalten werden kann, hält sich die benötigte Übertragungsleistung abhängig von der Anzahl der Transaktionen/s in Grenzen. Je nach Verfügbarkeit müsste man sich allerdings über Redundanz Gedanken machen. Das hängt aber alles stark vom Projekt selber ab - hier gibt es keine allgemeingültige Architektur für das System mehr.

Ähm.. und wo sollte dieser Transaktionsserver dann stehen? Bei mir? Und dann noch Kühlung und Belüftung bzw. insgesamt klimatisiert und Stromausfallsicherheit, etc. - klingt nicht besonders praktikabel.
Wenn der Transaktionsserver bei irgendwem - also z.b. bei mir - zuhause steht, ist das noch unsicherer als in einem RZ.
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 07:11:41 AM
#46
Wenn wir über Finaztransaktionsserver reden ...

dann ist noch die Frage, ob das Projekt genug Geld einbringt um eine (mehrere? Verfügbarkeitsanforderungen?) Standleitung zu finanzieren. Dann wäre es eine Option, den Transaktionsserver lokal zu halten. Damit wäre der einzige Zugang ins Netz die Transaktionsschnittstelle zu dem(den) dedizierten Prozessserver(n). Damit lässt sich eine sehr gute Absicherung realisieren. Da das Protokoll sehr effizient gehalten werden kann, hält sich die benötigte Übertragungsleistung abhängig von der Anzahl der Transaktionen/s in Grenzen. Je nach Verfügbarkeit müsste man sich allerdings über Redundanz Gedanken machen. Das hängt aber alles stark vom Projekt selber ab - hier gibt es keine allgemeingültige Architektur für das System mehr.

@TheOtherOne: Mich interessiert immer noch, warum man keine DB von der Stange und keine Standardbibliotheken im Backend nehmen kann und warum ganz allgemeingültig (lokaler?) root Zugriff das ganze Konzept vaporisieren soll.
newbie
Activity: 42
Merit: 0
November 09, 2013, 06:53:43 AM
#45
Bei Auslieferung nicht. Ein paar Minuten später schon. Allen anderen gehört der Server sofort wieder abgenommen - das hat die erste Aktion bei einem neuen Dedicated Server zu sein. Und gleich dazu gehören alle Services bis auf den Zugang erst mal dicht bis sie korrekt konfiguriert sind.

Darüber braucht man aber nicht mehr diskutieren das ist die Basiskonfiguration eine dedizierten Webserver. Wenn wir über Finaztransaktionsserver reden dann setze ich die grundlegenden Sache einfach als selbstverständlich voraus.

Ja, das hätte ich auch so gemacht, bin allerdings kein Experte auf diesem Gebiet.
legendary
Activity: 2618
Merit: 1253
November 09, 2013, 05:35:13 AM
#44
Das ist selbstverständlich. root hat bei einem Standardserver nie Remote Zugang und der Benutzer ist bei Remote Zugang in der Password DB gesperrt. Darüber braucht man nicht mal bei einem stinknormalen Webserver reden.
Ja wir reden aber schon von Root-Server(n) und da ist das nicht per Default so, ist ja schließlich ein Root-Server.
Nur mit einem Webserver kommt man bei diesem Projekt nicht so weit.

Bei Auslieferung nicht. Ein paar Minuten später schon. Allen anderen gehört der Server sofort wieder abgenommen - das hat die erste Aktion bei einem neuen Dedicated Server zu sein. Und gleich dazu gehören alle Services bis auf den Zugang erst mal dicht bis sie korrekt konfiguriert sind.

Darüber braucht man aber nicht mehr diskutieren das ist die Basiskonfiguration eine dedizierten Webserver. Wenn wir über Finaztransaktionsserver reden dann setze ich die grundlegenden Sache einfach als selbstverständlich voraus.
newbie
Activity: 42
Merit: 0
November 08, 2013, 05:30:07 PM
#43
Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Dann kann man den Port auch gleich offen lassen. Allerdings sollte Public Key Auth oder OTP ausreichend sein.

OTP klingt sehr gut. Scheint wie eine TAN-Liste zu funktionieren.

Das ist selbstverständlich. root hat bei einem Standardserver nie Remote Zugang und der Benutzer ist bei Remote Zugang in der Password DB gesperrt. Darüber braucht man nicht mal bei einem stinknormalen Webserver reden.

Ja wir reden aber schon von Root-Server(n) und da ist das nicht per Default so, ist ja schließlich ein Root-Server.
Nur mit einem Webserver kommt man bei diesem Projekt nicht so weit.
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 04:34:10 PM
#42
Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Dann kann man den Port auch gleich offen lassen. Allerdings sollte Public Key Auth oder OTP ausreichend sein.

TheOtherOne sprach aber davon, dass sich jemand SSH root-Zugang verschaffen könnte und damit sämtliche Sicherheitsvorrichtungen kompromittieren würde. Doch hier muss ich noch anfügen, dass es unabhängig vom Port sinnvoll wäre, den user root für ssh-login grundsätzlich zu sperren und vielleicht mit sudo arbeiten.

Das ist selbstverständlich. root hat bei einem Standardserver nie Remote Zugang und der Benutzer ist bei Remote Zugang in der Password DB gesperrt. Darüber braucht man nicht mal bei einem stinknormalen Webserver reden.
newbie
Activity: 42
Merit: 0
November 08, 2013, 03:57:16 PM
#41
Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.

Das musst Du mir jetzt erklären.


Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Das würde verhindern, dass irgendwer im Normalbetrieb auf die Shell kommt bzw. dies überhaupt versuchen kann.

Sich auf darauf verlassen, dass niemand den Port findet ist Scheinsicherheit.

Nein, ich rede nicht von einem versteckten Port. Der SSH-Port würde nur für Einspielungen von Änderungen (scp) und Adminstrationsaufgaben geöffnet werden und wäre ansonsten geschlossen, d.h. überhaupt nicht erreichbar.


Ich habe ehrlich gesagt lieber einen SSH am Port, als einen Webserver. Kennst Du einen Fall bei dem ein Server mit SSH Zugang, Public Key Auth und ordentlich generiertem Key gehackt worden ist? Dann gibt es natürlich noch ein paar Möglichkeiten vor und nach dem Login.

TheOtherOne sprach aber davon, dass sich jemand SSH root-Zugang verschaffen könnte und damit sämtliche Sicherheitsvorrichtungen kompromittieren würde. Doch hier muss ich noch anfügen, dass es unabhängig vom Port sinnvoll wäre, den user root für ssh-login grundsätzlich zu sperren und vielleicht mit sudo arbeiten.
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 03:10:07 PM
#40
Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.

Das musst Du mir jetzt erklären.


Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Das würde verhindern, dass irgendwer im Normalbetrieb auf die Shell kommt bzw. dies überhaupt versuchen kann.

Sich auf darauf verlassen, dass niemand den Port findet ist Scheinsicherheit. Ich habe ehrlich gesagt lieber einen SSH am Port, als einen Webserver. Kennst Du einen Fall bei dem ein Server mit SSH Zugang, Public Key Auth und ordentlich generiertem Key gehackt worden ist? Dann gibt es natürlich noch ein paar Möglichkeiten vor und nach dem Login. Mit einem Transaktionsserver vor Ort braucht man sich darüber gar keine Gedanken machen - dann gibt es erst gar keinen Remote Zugang.

Trotzdem muss der Rechner natürlich administrierbar sein hat also zumindest lokale root Rechte für den Admin (natürlich nicht für den Service). Ich Frage mich also immer noch, was TheOtherOne damit sagen wollte. Vor allem laufen Transaktionsserver mit entsprechender Absicherung und die hängen am Internet ohne dass sie gehackt werden. Bei ein paar Diensten wäre ein Einbruch tatsächlich fatal. Entsprechend gut sind sie gesichert.
newbie
Activity: 42
Merit: 0
November 08, 2013, 02:42:23 PM
#39
Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.

Das musst Du mir jetzt erklären.


Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Das würde verhindern, dass irgendwer im Normalbetrieb auf die Shell kommt bzw. dies überhaupt versuchen kann.
newbie
Activity: 42
Merit: 0
November 08, 2013, 02:29:11 PM
#38
Ihr solltet den Threadersteller mit ein bisschen Respekt behandeln, da gehe ich mit Polarstorm konform.
Schließlich hätte er auch einfach im Brigitteforum oder im Lawblog nach Mitstreitern suchen können - aber nein, er hat euch auserwählt. Anstatt sich dankbar zu zeigen, hackt ihr nur auf ihm rum; das gehört sich nicht.

LOL. Thx. Ich habe aber Zweifel, dass ich im Brigitteforum Leute gefunden hätte die a) derartige skills haben und b) was von Bitcoins wissen/verstehen

Sie hacken auf mir herum weil ich halt nicht genannt habe was die Idee ist. Das ist schon irgendwie blöd. Ist ähnlich wie wenn man Wochen vorher weiß dass man was supertolles zu Weihnachten geschenkt bekommt aber man weiß nicht was es ist. Unerträglich Cheesy


Deswegen: wo kann man denn eine closed group erstellen zu der man Leute einladen kann? Von Facebook habe ich mich gerade "gelöscht", nachdem man mich mundtot gemacht hat wie einen unmündigen Bürger. Ich durfte nichts mehr posten! Unverschämt. Gut, dass ich wieder aus dem Mainstream heraus bin.

Vielleicht gibt es solche closed groups in Diaspora? Ka.. melde mich gerade an..
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 02:23:01 PM
#37
Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.

Das musst Du mir jetzt erklären.
newbie
Activity: 42
Merit: 0
November 08, 2013, 01:26:08 PM
#36
Quote
Ja, wirklich. Wenn man das alles selbst programmieren will wird man ja nie fertig.

Ich verstehe das aber genau das ist das Problem.
Also ich würde Never-Ever einen Wallet/Transaktionsbasierten Dienst so hinstellen.

Edit: Aber ich will hier keinen Techno-Thread lostreten. Nur zu... Wink

Ich schrieb, dass Sicherheitsexperten benötigt werden bzw. zu begrüßen wären.
Deswegen ist eine Technologie-Diskussion durchaus angebracht. Wenn sich was eigenes realisieren und absichern lässt, wieso denn nicht?
Andererseits stecken in den vorhandenen Lösungen halt schon unzählige Stunden an Manpower und die haben sich zu Sicherheit auch viele Gedanken gemacht..
full member
Activity: 120
Merit: 100
November 08, 2013, 12:13:18 PM
#35
Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 11:57:42 AM
#34
Quote
Weil die Standardkomponenten inzwischen mehr oder weniger ausgereift sind und diese bei entsprechender Absicherung zusätzlich hinter eigenen Schnittstellen betrieben werden die diese zusätzlich vom Netz trennen.

Unsinn, Standardkomponenten widerspricht in sich schon Sicherheit
und Interpreter-Code lässt sich grundsätzlich nicht wirkungsvoll
*Obfuscaten*, keine Chance.

Warum ist die Sicherheit einer DB, welche vordefinierte Anfragen bearbeitet ausschlaggebend für die Sicherheit des Gesammtsystem?

Warum sollte Obfuscation für serverseitigen Code der den Server nicht verlässt wichtig sein?

Wir reden hier über ein abgestuftes Sicherheitskonzept. Da hängt weder die DB am Netz, noch der JS Code. Wenn es um das Transaktionssystem geht, hängt noch nicht mal ein Standarddienst am Netz.
full member
Activity: 120
Merit: 100
November 08, 2013, 11:55:19 AM
#33
Quote
Ja, wirklich. Wenn man das alles selbst programmieren will wird man ja nie fertig.

Ich verstehe das aber genau das ist das Problem.
Also ich würde Never-Ever einen Wallet/Transaktionsbasierten Dienst so hinstellen.

Edit: Aber ich will hier keinen Techno-Thread lostreten. Nur zu... Wink
full member
Activity: 120
Merit: 100
November 08, 2013, 11:52:07 AM
#32
Quote
Weil die Standardkomponenten inzwischen mehr oder weniger ausgereift sind und diese bei entsprechender Absicherung zusätzlich hinter eigenen Schnittstellen betrieben werden die diese zusätzlich vom Netz trennen.

Unsinn, Standardkomponenten widerspricht in sich schon Sicherheit
und Interpreter-Code lässt sich grundsätzlich nicht wirkungsvoll
*Obfuscaten*, keine Chance.
newbie
Activity: 42
Merit: 0
November 08, 2013, 11:51:10 AM
#31
Ich kann einfach nicht verstehen, warum bei
so vielen wichtigen Diensten immer noch Interpreter und Datenbanken
von der Stange genutzt werden.

Weil die Standardkomponenten inzwischen mehr oder weniger ausgereift sind und diese bei entsprechender Absicherung zusätzlich hinter eigenen Schnittstellen betrieben werden die diese zusätzlich vom Netz trennen.


Ja, wirklich. Wenn man das alles selbst programmieren will wird man ja nie fertig.

Es muss nicht ausgerechnet MySQL sein..
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 11:44:34 AM
#30
Ich kann einfach nicht verstehen, warum bei
so vielen wichtigen Diensten immer noch Interpreter und Datenbanken
von der Stange genutzt werden.

Weil die Standardkomponenten inzwischen mehr oder weniger ausgereift sind und diese bei entsprechender Absicherung zusätzlich hinter eigenen Schnittstellen betrieben werden die diese zusätzlich vom Netz trennen.
full member
Activity: 120
Merit: 100
November 08, 2013, 11:33:26 AM
#29
Node.js und MySQL etc. hören sich aber nun wirklich nicht nach einer
SICHEREN Plattform an. Ich kann einfach nicht verstehen, warum bei
so vielen wichtigen Diensten immer noch Interpreter und Datenbanken
von der Stange genutzt werden. Ist die Möhre einmal kompromittiert
liegt einfach ALLES offen. Vom DB-Zugang bis zur Cluster-Topologie
inkl. Zugang zur Cold-Wallet Storage.
newbie
Activity: 42
Merit: 0
November 08, 2013, 11:27:56 AM
#28
Ja sie ist einfach total vorsichtig, damit keiner zuvorkommt. Genau das ist es.

Aha... sie ?

Ja, ich.

Ich verstehe folgendes nicht :
Warum poolt man nicht die Ressourcen die man hat zusammen , engagiert ein paar fleißige Menschen unter Knebel- NDA , ist immer noch First to Market und profitiert dann ?
Also ich will niemanden mit einer NDA knebeln. Ich suche einfach Leute, die das ernst meinen und dann brauche ich sie nicht zu knebeln!

Webdesigner , welche für BTC arbeiten - Check.
Grafiker - Check. Ja , selbst Marketing-Menschen bekommt man dafür.
Also sorry. Einfach irgendwelche Leute beschäftigen, die nicht mal aus der Bitcoins-Community kommen? Das fühlt sich nicht richtig und echt an!

Anonymität so wichtig ? Also ist es nicht-legal ? Die Idee ist nonsens und niemand würde dafür Geld geben ?

Nein. Wo sprach ich denn von Anonymität? Auf Bitcoins möchte ich setzen, weil man sich dann nicht selbst um den ganzen AML-Banken-Scheiß kümmern muss, wie man es bei Konten in EUR z.b. machen müsste, weil sonst bei größeren bewegten Summe diese Wahnsinnigen mit ihrem Geldwäsche-Kram kämen und das Projekt dicht machen würden "this domain has been seized" heißt es dann z.B. Der AML-Kram passiert auf der Exchanger-Seite und man hat als Bitcoins-Projekt damit nichts zu tun. Das wäre nämlich ein riesiger Verwaltungsaufwand wenn man jeden Benutzer auf seine Identität prüfen müsste!

Wenn die Idee nonsens wäre, dann hätte ich sie einmal gehabt und sie wäre wieder verflogen, tauchte aber immer und immer wieder auf.

Was ist los ? Satoshi hat sogar in einer öffentlichen Mailing-Liste sein Whitepaper und seine Ideen veröffentlicht. Und seine Umsetzung dieser Ideen ist warscheinlich die größte und genialste Idee seit Anbeginn der Wirtschaft auf diesem Planeten.
Die Idee hat direkt mit Bitcoins nichts zu tun, ist jetzt aber zu einer Bitcoins-Idee geworden.
Du hast Recht. Satoshis-Idee ist besser als diese, ich verneige mein Haupt, lol.

Und die hat ihm niemand geklaut, ist sogar oft kopiert.
Ja das Kopieren ist doch aber "klauen". Vielleicht habe ich da noch so viel falsches Ego. Ich arbeite daran. Bisweilen aber basiere ich mich auf meinen schlechten Erfahrungen als ich bereits Ideen veröffentlichte und dann ja nicht mal mehr selbst mitwirken konnte. Da kommste dir echt blöd vor, wenn du die Idee hattest aber du dann nichts mehr damit zu tun hattest.


Und der Grund warum wir hier sind.
Ja, das ist wirklich die beste Idee seit Anbeginn der Wirtschaft bzw. des Geldes. Die herkömmlichen Währungen (kein Geld, nur Währungen) können einpacken.
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 11:14:08 AM
#27
LTC,TRC,DEM sind Kopien dieser Idee, hab ich was anderes behauptet?

Nein, aber ich falsch gelesen...
legendary
Activity: 2270
Merit: 1363
November 08, 2013, 11:09:55 AM
#26
Was ist los ? Satoshi hat sogar in einer öffentlichen Mailing-Liste sein Whitepaper und seine Ideen veröffentlicht. Und seine Umsetzung dieser Ideen ist warscheinlich die größte und genialste Idee seit Anbeginn der Wirtschaft auf diesem Planeten.

Und die hat ihm niemand geklaut, ist sogar oft kopiert.

Das stimmt so nicht. LTC, TRC, DEM, ...

Ausserdem frage ich mich immer, wie gut eine Idee ist, die sich nur Aufgrund eines NDA oder Monopolschutz zu Geld machen lässt - falls Geld das Ziel ist.


LTC,TRC,DEM sind Kopien dieser Idee, hab ich was anderes behauptet?
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 10:39:58 AM
#25
Was ist los ? Satoshi hat sogar in einer öffentlichen Mailing-Liste sein Whitepaper und seine Ideen veröffentlicht. Und seine Umsetzung dieser Ideen ist warscheinlich die größte und genialste Idee seit Anbeginn der Wirtschaft auf diesem Planeten.

Und die hat ihm niemand geklaut, ist sogar oft kopiert.

Das stimmt so nicht. LTC, TRC, DEM, ...

Ausserdem frage ich mich immer, wie gut eine Idee ist, die sich nur Aufgrund eines NDA oder Monopolschutz zu Geld machen lässt - falls Geld das Ziel ist.
legendary
Activity: 2270
Merit: 1363
November 08, 2013, 08:50:38 AM
#24

Ja sie ist einfach total vorsichtig, damit keiner zuvorkommt. Genau das ist es.


Aha... sie ?

Ich verstehe folgendes nicht :

Warum poolt man nicht die Ressourcen die man hat zusammen , engagiert ein paar fleißige Menschen unter Knebel- NDA , ist immer noch First to Market und profitiert dann ?

Webdesigner , welche für BTC arbeiten - Check.
Grafiker - Check.

Ja , selbst Marketing-Menschen bekommt man dafür.

Anonymität so wichtig ? Also ist es nicht-legal ? Die Idee ist nonsens und niemand würde dafür Geld geben ?

Was ist los ? Satoshi hat sogar in einer öffentlichen Mailing-Liste sein Whitepaper und seine Ideen veröffentlicht. Und seine Umsetzung dieser Ideen ist warscheinlich die größte und genialste Idee seit Anbeginn der Wirtschaft auf diesem Planeten.

Und die hat ihm niemand geklaut, ist sogar oft kopiert.

Und der Grund warum wir hier sind.
legendary
Activity: 879
Merit: 1000
monero
November 08, 2013, 07:04:53 AM
#23
ich glaube da ist was beim zitieren durcheinander geraten  Wink
newbie
Activity: 42
Merit: 0
November 08, 2013, 06:57:09 AM
#22
Aber mal im ernst, glaubst du wirklich ich würde mich so ausdrücken und würde mir für sowas nen 2. acc holen ?

Paranoia ?

Also das ist wirklich völlig absurd. Keine Ahnung, was er genau postete, doch das hier ist unique. Und dann auch noch

Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...
Du meinst falls die Seite nicht profitabel ist?

Ich denke eher, weil ein Hacker vorbeikommt und sich die Hot Wallet ausräumt oder der Betreiber das selber macht (das kann man von aussen nicht unterscheiden).


Also dagegen dass ein Hacker vorbeikommt und was ausräumt muss man den/die Server natürlich absichern. Zumindest ausreichend, damit es ihm schlicht zu lange dauert und er sich ein neues Ziel sucht usw. Es gibt da unterschiedliche Szenarien. Das ist schon Grund genug für ein derartiges Projekt auf PHP zu verzichten.

Tja, hm, bezüglich des Betreibers muss man wohl Vertrauen haben. Ähnlich wie bei sonstigen Online Wallets.

legendary
Activity: 2618
Merit: 1253
November 08, 2013, 06:52:54 AM
#21
Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...
Du meinst falls die Seite nicht profitabel ist?

Ich denke eher, weil ein Hacker vorbeikommt und sich die Hot Wallet ausräumt oder der Betreiber das selber macht (das kann man von aussen nicht unterscheiden).
newbie
Activity: 42
Merit: 0
November 08, 2013, 06:49:52 AM
#20
Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...

Falls Online Transaktionen geplant sind: Das kann man gar nicht dick genug schreiben!

Meiner Meinung nach darf die Hot Wallet niemals auf dem Prozesssystem liegen. Idealerweise läuft die Kommunikation mit dem Transaktionssystem über eine eigene Schnittstelle, die entsprechend überwacht wird und bei Abweichungen eine abgestufte Reaktion vom Alarm bis hin zur Abschaltung, notfalls One Way, liefert.


Genau wegen so etwas benötigt das Projekt Sicherheitsexperten. Ich versteh den Kram zwar halbwegs, aber ich finde nicht, dass ich genug Sicherheitsexperte bin um Bitcoins anderer zu verwalten. Also gemeint ist natürlich vor allem die Sicherheit der Wallets und Transaktionen (halt deposit und withdraw) - der rest müsste ja intern ablaufen, schon um keinen blockchain spam zu verursachen).
Seit gestern mit inputs.io weiß man dass man sich auf Dritte auch nicht immer so direkt verlassen kann...

Eine eigene Machine für das Hot-Wallet könnte sich ja vielleicht einrichten lassen. Diesbezüglich muss noch viel geplant werden.
newbie
Activity: 42
Merit: 0
November 08, 2013, 06:38:27 AM
#19
Im Endeffekt willst du also Bitcoins annehmen (und dann eventuell irgendwann auch wieder auszahlen) die auf deiner Plattform für irgendwas gehandelt werden können, sei es WoW Gold, Pizza oder Nacktbilder (alle 3 Möglichkeiten gibt es übrigens schon, teils seit Jahren).
Pizza Cheesy Cheesy

Warum erst jetzt - hätte das nicht mit Paypal (dann eben mit höheren Gebühren, um Fraudrate auszugleichen) funktioniert? Wenn man Paypal nicht traut, dann eben Banküberweisung oder sonstige bisher existierende Geldtransfermechanismen... - wo ist die Spezifität zu Bitcoin?

Ja, ich wollte das zunächst mit Paypal machen, erkannt dann aber dass es mit Bitcoins alleine technisch schon schöner umzusetzen ist.
Warum erst jetzt... die Idee reift schon länger. Ich hatte noch keine Zeit dafür.

Was macht dich/deine Firma vertrauenswürdig genug, meine Bitcoins dorthinzusenden und darauf zu vertrauen, da auch jemals wieder was zurück zu bekommen? Wie kann man dich verklagen und wieso hast du keine Angst davor, dass du von mir verklagt werden könntest?
Warum suchst du in einem Forum nach Leuten von irgendwoher um Hilfe, statt in deinem Freundes- und Bekanntenkreis?
Nach dem inputs.io "hack" oder "rob" sehe ich mich nicht in der Lage davon zu sprechen, dass man mir vertrauen kann. Denn die hatten TradeFortress ja auch vertraut.


Übrigens willst du, dass Leute NDAs unterschreiben... dir ist schon klar, dass du da auch mit deinem echten Namen unterschreiben musst (und "amunet" oder ein GPG clearsign ist da leider nicht ausreichend)?
Ich muss gar nichts. Du sprichst das an für den Fall, dass ich jemanden der sich nicht dran hält verklagen möchte und damit würde ich mit der Angst vor Geldstrafen und Strafverfolgung spielen. Ich glaube nicht an dieses Matrix-Kontroll-System. Auch mein Name im System ist keineswegs "echt". Das bin nicht ich, es ist nur ein Agent (aus dem Englischen) zu dem Daten gespeichert werden und zu dem sich andere ein Bild über "mich" machen, doch ich bin unendliches Bewusstsein, das ursprünglich nicht mal einen Namen hatte!! Deswegen trage ich ihn heute quasi nur noch in der Hosentasche und brauche ihn nur für das Game mit dem System. Es ist nicht mein Name. Also nicht etwas was ich besitze oder was wirklich zu mir gehört. Es ist mehr wie eine Referenz auf die Entität des unendliches Bewusstseins, was ich verkörpere. Aber damit will ich hier nur untermalen, wie bedeutungslos "echte" Namen sind. Es geht am Ende immer um Begegnungen zwischen zwei Seelen und wenn eine verspricht "ja ich erzähl die Idee nicht weiter" und es trotzdem tut, dann hat dies unweigerlich auch Auswirkungen auf diese Seele. Deswegen sind viele Anwälte und Rechtsleute sowas von kaputt. Sie verdrehen die Wahrheit jeden Tag. Alles klar. Ich muss das also nicht, sondern gehe den Weg meines Spirits. Dann finde ich schon die passenden, aufrichtigen Leute und bedarf keinerlei Recht.


aber leider habe ich schon dutzende (nein, ich übertreibe NICHT!) Posts gelesen, die ziemlich genau gleich wie deiner geklungen haben, strukturiert waren und auch fast den gleichen Inhalt hatten.
Ok, das kann ich verstehen auch wenn ich meine, dass die meisten nicht so lang gewesen sind. Smiley

Die einzigen Projekte in diesem Forum, die bisher dann wirklich was auf die Beine gestellt hatten, waren candoo und mybitcointrade. Beide haben im Endeffekt ein paar 1000€ oder mehr verbrannt und das war's.

Hm. Eventuell muss solch eine Idee also noch weiter reifen. Ich mein das ernst und will das zum Erfolg bringen in der ein oder anderen Form.
Ka, was da los war aber ich nehme an, dass dabei die meisten Leute halt einfach aufgegeben hatten.

Alleingänge im stillen Kämmerchen endeten dann meist so wie TradeFortress (inputs.io), Tom Williams (mywallet oder wie das damals hieß), pirateat40 (gut, der war im Endeffekt einfach nur ein scammer, hatte aber auch 2 nette Plattformen gecodet) oder Zhou Tong (bitcoinica). Es gibt aber auch ein paar erfolgreiche Alleingänge, z.B. Armory.

lol. Aber es ist halt auch sicher verlockend und lukrativ bei so vielen Bitcoins. Der inputs.io rob hat die wohl zu Millionären gemacht.
Nun, ich sprach von einem shared wallet. Dieses shared wallet wäre diesbezüglich eine erhöhte Sicherheit, weil ja jeder nur seinen Teil wieder heraus holen kann.


Die wirklich erfolgreichen Projekte allerdings wurden hier erst vorgestellt, als zumindest eine funktionale Beta vorhanden war, wenn nicht gar das fertige Produkt. Zumindest aber eine Idee.

Das hier ist ja noch pre-alpha, also kann es keine funktionale Beta geben. Wenn ich eine Beta präsentieren würde, dann würde diese schnell kopiert werden. Hm.


Wie schon gesagt - wenn es wirklich so simpel ist, die Idee zu kopieren, dann sollte man sich überlegen, wieso das einerseits noch niemand getan hat und andererseits wie man den Vorsprung ausnutzen kann, den man evnetuell erhält, wenn man der erste ist.

Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...

Du meinst falls die Seite nicht profitabel ist? Das muss man mit Gebühren bewerkstelligen. Wie ein Faucet kann man sowas natürlich nicht betreiben.
Ist das der Grund wieso diese Seiten scheiterten und dann dicht machen mussten? So wird es wohl gewesen sein. Nicht genug Bitcoins mehr da und dann waren auch die Leute weg, na toll. Deswegen such ich auch gar nicht Leute, die damit Geld verdienen wollen, wirklich. Die Absicht ist am Ende natürlich Profit, gerade auch für die Benutzer diese Möglichkeit schaffen, weil "Geld verdienen im Internet" ansonsten doch meist eh nur scam ist und ich eben möchte dass es was richtiges wird Cheesy, doch wer dabei sein will dann sicher nicht primär um damit einen Einkommens-Strom zu erschaffen. Das heißt nicht dass es keine Bezahlung geben kann oder dass das ein No-Cost Projekt sein muss. Doch gerade auf Hinblick des Erfolgs eines großen Projektes wäre es sinnvoll die meisten Funds eben ins Hotwallet zu stecken.

Mir ist schon klar dass ich früher oder später den Kern der Idee enthüllen werden muss.
sr. member
Activity: 406
Merit: 250
November 08, 2013, 05:53:41 AM
#18
lol ja, will garnich abstreiten das es da gewisse Paralellen gibt in der Art des Angebots und den Sorgen des TEs.

Aber mal im ernst, glaubst du wirklich ich würde mich so ausdrücken und würde mir für sowas nen 2. acc holen ?

Paranoia ?



Habe gestern übrigens noch ein Skype Gespräch mit dem TE geführt. Details hab ich keine erfahren, ging eher um allgemeines, also was für Kapazitäten er braucht, was er selbst machen kann usw.
Mein momentaner Eindruck ist, das er einfach sehr vorsichtig sein möchte und nicht will das ihm irgendwer zuvorkommt (was ich sehr gut nachvollziehen kann). Darüber hinaus will er Leuten die mitmachen durchaus Einblick gewähren.

Für mich kam ein allgemeiner Einstieg nicht in Frage weil ich mit meinen eigenen Sachen gut beschäftigt bin, aber da er auch Grafik/Animation etc sucht, dachte ich mir es könnte nicht schaden mal mit ihm zu reden und so simma auch erstmal verblieben.
legendary
Activity: 879
Merit: 1000
monero
November 08, 2013, 04:23:04 AM
#17
Klingt schwer nach nem polarstorm alt  Grin
Hoffentlich werd' ich jetzt nicht angezeigt...
legendary
Activity: 2618
Merit: 1253
November 08, 2013, 02:46:48 AM
#16
Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...

Falls Online Transaktionen geplant sind: Das kann man gar nicht dick genug schreiben!

Meiner Meinung nach darf die Hot Wallet niemals auf dem Prozesssystem liegen. Idealerweise läuft die Kommunikation mit dem Transaktionssystem über eine eigene Schnittstelle, die entsprechend überwacht wird und bei Abweichungen eine abgestufte Reaktion vom Alarm bis hin zur Abschaltung, notfalls One Way, liefert.
legendary
Activity: 2618
Merit: 1006
November 07, 2013, 08:05:21 PM
#15
Im Endeffekt willst du also Bitcoins annehmen (und dann eventuell irgendwann auch wieder auszahlen) die auf deiner Plattform für irgendwas gehandelt werden können, sei es WoW Gold, Pizza oder Nacktbilder (alle 3 Möglichkeiten gibt es übrigens schon, teils seit Jahren).

Meine üblichen Fragen sind dann meist:
Warum erst jetzt - hätte das nicht mit Paypal (dann eben mit höheren Gebühren, um Fraudrate auszugleichen) funktioniert? Wenn man Paypal nicht traut, dann eben Banküberweisung oder sonstige bisher existierende Geldtransfermechanismen... - wo ist die Spezifität zu Bitcoin?
Was macht dich/deine Firma vertrauenswürdig genug, meine Bitcoins dorthinzusenden und darauf zu vertrauen, da auch jemals wieder was zurück zu bekommen? Wie kann man dich verklagen und wieso hast du keine Angst davor, dass du von mir verklagt werden könntest?
Warum suchst du in einem Forum nach Leuten von irgendwoher um Hilfe, statt in deinem Freundes- und Bekanntenkreis?


Übrigens willst du, dass Leute NDAs unterschreiben... dir ist schon klar, dass du da auch mit deinem echten Namen unterschreiben musst (und "amunet" oder ein GPG clearsign ist da leider nicht ausreichend)?

Sorry wenn das jetzt wieder so negativ klingt wie Polarstorm immer meckert, aber leider habe ich schon dutzende (nein, ich übertreibe NICHT!) Posts gelesen, die ziemlich genau gleich wie deiner geklungen haben, strukturiert waren und auch fast den gleichen Inhalt hatten. Die einzigen Projekte in diesem Forum, die bisher dann wirklich was auf die Beine gestellt hatten, waren candoo und mybitcointrade. Beide haben im Endeffekt ein paar 1000€ oder mehr verbrannt und das war's. Alleingänge im stillen Kämmerchen endeten dann meist so wie TradeFortress (inputs.io), Tom Williams (mywallet oder wie das damals hieß), pirateat40 (gut, der war im Endeffekt einfach nur ein scammer, hatte aber auch 2 nette Plattformen gecodet) oder Zhou Tong (bitcoinica). Es gibt aber auch ein paar erfolgreiche Alleingänge, z.B. Armory.
Die wirklich erfolgreichen Projekte allerdings wurden hier erst vorgestellt, als zumindest eine funktionale Beta vorhanden war, wenn nicht gar das fertige Produkt. Zumindest aber eine Idee.

Wie schon gesagt - wenn es wirklich so simpel ist, die Idee zu kopieren, dann sollte man sich überlegen, wieso das einerseits noch niemand getan hat und andererseits wie man den Vorsprung ausnutzen kann, den man evnetuell erhält, wenn man der erste ist.

Viel Glück und immer brav auf die Hotwallet achten - die wird nämlich erfahrungsgemäß eines Tages leer sein...
hero member
Activity: 803
Merit: 500
November 07, 2013, 04:33:53 PM
#14
na dann bin ich mal gespannt, was daraus wird ... deine Überschrift lässt leider nicht gerade auf einen Kopf schließen, der "die größte und genialste Idee seit ..." austüftelt

was dir jetzt noch fehlt, ist ein Geistesblitz, wie du spannende Anreisser für deine Idee mitteilst, ohne zuviel zu verraten. Wenn du willst, helfe ich dir dabei via pm. Und keine Sorge - ich habe kein Interesse daran, ein Projekt oder eine Kopie aufzustellen, ich bin ein Autor, kein Programmierer oder Projektmanager. Wenn die Idee gut ist, helfe ich dir im Rahmen meiner Möglichkeiten und zeitlichen Ressourcen.
sr. member
Activity: 406
Merit: 250
November 07, 2013, 11:08:14 AM
#13
Hast ne PN
newbie
Activity: 42
Merit: 0
November 07, 2013, 11:03:02 AM
#12
Mit so einer Ankündigung und so wenig Informationen ist das kein Wunder. Ehrlich gesagt kenne ich kein Projekt, welches nach so einer vollmundigen Ankündigung ein echter Burner geworden wäre. Dagegen gibt es einige die mit deutlich weniger Trommeln die Welt verändert haben.

Damit ist klar in welcher Schublade Du, unabhängig vom Projekt, mit dieser Ankündigung landest. Marketing ist gut, geht aber bei nicht zielgruppengerechter Übertreibung so ziemlich nach hinten los.


Das war ja keine Werbung an sich, sondern mehr ein Gesuch für Mitwirkende.

Gegen Vollmundigkeit habe ich nun gar nichts. Und eben vollmundige Leute suche ich, die ihre Skills verstehen und einsetzen können.

So aber ich wart jetzt erstmal was noch für Reaktionen kommen bevor ich irgendetwas ändere.

Auch die beste Idee braucht Promotion um es überhaupt bekannt zu machen. Damit die Leute was zum gucken haben sollte es heutzutage ein Video sein.

Wenn ich verraten würde in was an investieren kann, würde ich bereits die eigentliche Idee verraten, was ich natürlich nicht direkt tat, da sie nur einem erlesenem Kreis mitgeteilt werden soll sonst dauert es nur einige Wochen oder sogar nur Tage und es gibt mindestens eine minderwertige Umsetzung davon und das möchte ich nicht Cheesy
legendary
Activity: 3657
Merit: 1448
November 07, 2013, 10:58:12 AM
#11
Aber dass das wie MLM rüber kommt entsetzt mich jetzt ein wenig.

Naja, in Deinen "Details" sagst Du ja lediglich, daß die Nutzer investieren (in was?) und traden können.
Außerdem suchst Du Leute, die awesome promotion videos for youtube and so on basteln können (was die größte und genialste Idee seit Anbeginn der Zeit vermutlich garnicht nötig hätte),
was anderes als MLM viel mir dazu dann nicht ein.  Cheesy
legendary
Activity: 2618
Merit: 1253
November 07, 2013, 10:56:12 AM
#10
Mit so einer Ankündigung und so wenig Informationen ist das kein Wunder. Ehrlich gesagt kenne ich kein Projekt, welches nach so einer vollmundigen Ankündigung ein echter Burner geworden wäre. Dagegen gibt es einige die mit deutlich weniger Trommeln die Welt verändert haben.

Damit ist klar in welcher Schublade Du, unabhängig vom Projekt, mit dieser Ankündigung landest. Marketing ist gut, geht aber bei nicht zielgruppengerechter Übertreibung so ziemlich nach hinten los.
newbie
Activity: 42
Merit: 0
November 07, 2013, 10:50:46 AM
#9
Ja hängt euch doch nicht am Thread-Titel auf...

Aber dass das wie MLM rüber kommt entsetzt mich jetzt ein wenig.

Polarstorm: ich kann das gut verstehen. Ich wurde in den letzten 4 bis 8 Wochen um fast 700 USD gescammt und habe den ganzen scam mittlerweile total satt. Es nimmt wirklich überhand und wirkliche Unternehmen müssen sich immer mehr rechtfertigen, um erstmal ernst genommen zu werden.
sr. member
Activity: 406
Merit: 250
November 07, 2013, 10:47:33 AM
#8
Gott kotzt mich dieses Scam Geschreie hier an.

Das erst beste was hier einige Leute zu tun haben ist "scam" zu schreien, ganz egal um was es geht.

Ich hab den thread des TEs nicht gelesen, es ist mir auch egal was da drin steht, ich wollt mich nur grad malwieder über dieses ewige genörgel hier aufregen.
legendary
Activity: 3657
Merit: 1448
November 07, 2013, 10:46:24 AM
#7
Nicht alle Details genannt?
Ich seh da praktisch keine Details, nichtmal einen verpixelten Umriss.

Es macht den Anschein (!) eines "MultiLevelMarketing Exchanges", mehr kann man aus den angegebenen "Details" nicht erraten.
Das wäre dann zumindest eine Idee, aber die größte und genialste seit Anbeginn der Wirtschaft?  Roll Eyes
Wohl eher nicht.
legendary
Activity: 2618
Merit: 1253
November 07, 2013, 10:44:24 AM
#6
hört sich bei mir nach dem grössten und genialsten SCAM an Grin

Nee, so starten Projekte die die Welt verändern.  Wink
newbie
Activity: 42
Merit: 0
November 07, 2013, 10:43:59 AM
#5
Dann bitte einen besseren Vorschlag für den Titel machen. Dieser sollte ja auch Aufmerksamkeit erwecken.

Ich hatte auch schon oft vermeintlich gute Ideen, die sich als schlecht heraus stellten, doch diese reift schon seit längerer Zeit. Es war einer dieser berüchtigten Geistesblitze.
Nyx
sr. member
Activity: 274
Merit: 250
November 07, 2013, 10:39:25 AM
#4
hört sich bei mir nach dem grössten und genialsten SCAM an Grin

Du scheidest damit also schon aus. Ich meine das wirklich ernst und suche ausschließlich Leute, die das realisieren wollen und keine Trolle.

An sich verstehe ich das schon, da ich nicht alle Details genannt habe. Wenn du diese kennen würdest, würdest du das einsehen.

als kleiner Tipp würde ich evtl. die Überschrift ein wenig abändern. Mein Hauptkritikpunkt liegt an den Worten grösste und genialste Idee. Ehrlich gesagt hatten das hier schon viele...

Viel Erfolg auf jeden Fall bei deinem Projekt.
newbie
Activity: 42
Merit: 0
November 07, 2013, 10:37:55 AM
#3
hört sich bei mir nach dem grössten und genialsten SCAM an Grin

Du scheidest damit also schon aus. Ich meine das wirklich ernst und suche ausschließlich Leute, die das realisieren wollen und keine Trolle.

An sich verstehe ich das schon, da ich nicht alle Details genannt habe. Wenn du diese kennen würdest, würdest du das einsehen.
Nyx
sr. member
Activity: 274
Merit: 250
November 07, 2013, 10:35:25 AM
#2
hört sich bei mir nach dem grössten und genialsten SCAM an Grin
newbie
Activity: 42
Merit: 0
November 07, 2013, 10:31:43 AM
#1
Dies ist nur ein deutschsprachiger Hinweis auf meine Projektidee im englischsprachigem Forum, die allerdings
international und mehrsprachig umgesetzt werden sollte und natürlich sind Leute unterschiedlicher Sprachen
gesucht.

https://bitcointalksearch.org/topic/a-great-idea-that-is-worth-to-be-realized-327025
Jump to: