Hier ist jemand, der vielleicht mal einen spontanen Besuch machen könnten: Und mein Angebot den "3-Buchstabentyp" zu begleiten steht immernoch, da ich quasi um die Ecke wohne  |
|
|
|
So this will be able to have a fix but requires convincing of the largest pools.
Yes. Miners are able to immediately require higher fees for these transactions or to ignore these transactions when they create blocks. |
|
|
|
Diese Idioten! Dabei weiß doch jeder, dass griech. Banken gar kein Geld haben!
Zumindest geben sie kein Geld raus.  |
|
|
|
Nice security research. Can this attack be made profitable, or is it just DoS?
This "attack" is a nuisance just like the HighS malleability. Is fixing of this issue requiring a full 'hard forking'
No. As trout already wrote the miners can just take a higher fee for transactions with a large number of SIGOPS. 1) You are missing that miners are interested in fees. They have a right to include/exclude any transaction.
They might be interested in the BTC value, too. So it's interesting for them to include all transactions to preserve the value of their BTC. |
|
|
|
Nur was bringt es dir den Channel zum Gemüsehändler zu haben wenn das bedeutet du musst Bitcoins im Voraus auf LN laden? damit du dann schnel bezahlen kannst? Dann kannst du die Bitcoins nicht für was anderes nutzen. Und wenn man einen Channel für jede Transaktion aufmacht um keine Bitcoins zu binden, dann kann man sich LN gleich sparen weil es nur mehr Arbeit bedeuten würde.
Teilweise richtig. Allerdings ist das - zumindest bei mir - heute auch mit Fiat schon anders. Auf dem Girokonto liegt immer ein gewisser Betrag, mit dem ich dann regelmässige Zahlungen veranlasse. Ich bringe das Geld nicht für jede einzelne Überweisung/Abbuchung zur Bank. Genauso hole ich nicht für jeden einzelnen Einkauf Bargeld, sondern ich habe meistens einen gewissen Betrag im Geldbeutel, mit dem ich dann viele Einkäufe durchführe. Für Einzeltransaktionen ist es natürlich nicht sinnvoll, da ein Zahlungskanal mehr Platz benötigt als die einzelne Transaktion. Wenn ich mit Dir genau ein Geschäft mache und wir auch keinen gemeinsamen Geschäftspartner haben, der jeweils einen Zahlungskanal zu jedem von uns geöffnet hat, dann wird das auch in Zukunft über eine einzelne Transaktion abgewickelt. Haben wir allerdings solche Zahlungskanäle, dann wäre es Optimal, das Geschäft darüber abzuwickeln. |
|
|
|
Also günstiger mit LN und 1MB blocks... das wird sicher nicht passieren.
LN funktioniert noch gar nicht mit Bitcoin, da hier noch ein paar Funktionen fehlen. Die Block Size kann bei wachsendem Volumen auch mit LN nicht bei 1MB bleiben, da der Aufbau der Zahlungskanäle und die Finalisierung ebenfalls Platz in der Blockchain benötigt. Allerdings bietet LN die Chance, einen Teil der Transaktionslast Off-Chain durchzuführen. Der Preis ist gebundene Liquidität. Dafür bekommt man im Gegenzug sofort wirksame Transaktionen ohne Fee. Im Prinzip ist LN (nur) eine (von vielen) Applikation (Multisig Escrow ist eine andere), die auf Bitcoin basiert. |
|
|
|
Ich leite im Augenblick solche Transaktionen beispielweise gar nicht mehr weiter.
Mein Interesse: Wie realisierst du das? Geht das mit Bitcoind? Oder past den entsprechend an? Ich habe den AcceptToMemoryPool() Code in bitcoin-core angepasst (ähnlich wie hier: https://github.com/bitcoin/bitcoin/pull/7081). Da ich nur Relay Nodes betreibe, habe ich im Augenblick ein absolutes Limit und keine Priorisierung drin. Als Miner würde ich eher priorisieren und gleichzeitig eine hohe Fee für die Aufnahme in einen Block verlangen. |
|
|
|
Ich glaube ihr überschätzt die etablierten Banken massiv. Manipulation sind deren tägliches Geschäft seit hunderten von Jahren. Technische Neuentwicklungen sind genau das Gegenteil davon.
Hier der passende Link, dem man diese Aussage entnehmen kann: http://heise.de/-3026417 |
|
|
|
|
Dazu kommt, dass unser Freund Alister Maclin gerade Transaktionen erzeugt, die das SIGOPS Limit ausnutzen. Das freut die Miner, das die Fee steigt, aber für die anderen Nutzer ist es ärgerlich. Damit passen gerade deutlich weniger "normale" TX in einen Block und die Blöcke lassen sich nicht mehr füllen.
Ein Miner könnten natürlich die TX filtern und Transaktionen mit einer grossen Anzahl an SIGOPS herunterpriorisieren. Das liegt komplett in der Hand eines Miners. Ich leite im Augenblick solche Transaktionen beispielweise gar nicht mehr weiter.
|
|
|
|
Ich bin mir nicht sicher dass die meisten Geschäfte immer wieder mit den gleichen Geschäftspartnern ablaufen. Ich denke einer der Geschäftspartner mag der selbe sein, aber nicht beide.
Selbst wenn ich überlege dass zB kraken.com so einen Paymentchannel einrichtet und ich soll darüber Einzahlungen machen. Das lohnt sich überhaupt nicht. Ich müsste Bitcoins im Voraus blockieren. Da hab ich mehr Arbeit als es Sinn macht.
Ich habe schon viele Geschäftspartner, bei denen ich immer wieder Einkaufe: Bäcker, Metzger, Gemüse, Supermarkt, Tankstelle, diverse Elektrogeschäfte, Provider und noch ein paar andere. Ohne Liquidität bringt es natürlich nichts, aber gerade LN kann durch das Konzept mit einem oder mehreren Zahlungsvermittlern in der Kette die Anzahl der notwendigen direkten Partner reduzieren. Damit könnte man für die lokalen Geschäfte z.B. nur einen Channel zum Gemüsehändler haben, durch Vernetzung aber auch sicher beim Bäcker und beim Metzger einkaufen. Ein lokales Netzwerk würde dann sogar teilweise die Vorteile einer Lokalwährung bringen, aber ohne die lästigen Beschränkungen bei Geschäften mit externen Geschäftspartnern. Wie gesagt, es geht hier nicht darum, Bitcoin durch LN zu ersetzen. Es ist nur eine von mehreren Anwendungsmöglichkeiten. |
|
|
|
|
Ideal wäre eine Mischnung. Die 1MB müssen sicher angehoben werden, andererseits bietet der Ansatz mit LN die Chance auf eine deutlich höhere Transaktionsrate. Wenn man anschaut, dass die meisten Geschäfte immer wieder mit den gleichen Geschäftspartnern ablaufen, bietet sich so ein Off-Chain Ansatz an um die Transaktionsleistung deutlich zu steigern.
|
|
|
|
|
Ich glaube ihr überschätzt die etablierten Banken massiv. Manipulation sind deren tägliches Geschäft seit hunderten von Jahren. Technische Neuentwicklungen sind genau das Gegenteil davon. Ausser ein paar Präsentation haben die etablierten Banken mit mit Bitcoin praktisch nichts zu tun und das wird auch noch lange so bleiben.
|
|
|
|
Aber ist es nicht so dass B das Geld erst sicher hat wenn er den Kontostand glatt gestellt hat, also auch Bitcoins am Ende bekommen hat? Der ganze Zweck von LN besteht doch aber offenbar darin dass man nicht sofort glatt stellt, sondern erstmal sammelt und dann mit einer Bitcointransaktion mehrere kleine interne Transaktionen glatt stellt. Heißt dass dann nicht dass, wenn der Transaction Channel zusammenbricht, die Daten verlorengehen, die Glattstellung nicht mehr erfolgen kann?
Ein Geschäftspartner hat die notwendigen Transaktionen in der Hand, um sofort den Channel zu schliessen und den aktuellen Geschäftsstand in der Blockchain zu fixieren. Sollte ein Geschäftspartner sich nicht mehr an die Vereinbarungen halten bzw. verschwinden, kann der andere Geschäftspartner den vollen Wert des Channel nach einer Wartezeit für sich beanspruchen. D.h. es ist im beiderseitigen Interesse die ursprüngliche Vereinbarung einzuhalten. An dem Punkt wäre es gut wenn der Payment Channel nicht nur eine Sache zwischen diesen beiden Parteien wäre sondern dritte die vorherigen Transaktionen nachvollziehen könnten, so dass sie wiederhergestellt werden können.
Oder welche Sicherung gibt es für den Fall?
Für sofort wirksame Übertragungen ist ein Payment Channel bzw. LN die richtige Wahl. Dafür wird man weiterhin Bitcoin direkt nutzen. LN wird erst bei einer längerfristigen Geschäftsbeziehung mit mehreren Zahlungen interessant. Die LN Beziehung wird dabei über die Blockchain abgesichert. Zur Absicherung hat jeder Geschäftspartner vom jeweils anderen eine signierte Transaktion in der Hand, mit denen er seine Ansprüche durch Übertragung dieser Transaktion in der Blockchain fixieren kann. Ah ok, die Sicherung besteht also darin dass der Empfänger eine gültige Bitcointransaktion hat die er propagieren kann wenn der Paymentchannel zusammenbricht. Also muss der Empfänger nur, wenn er sich absichern will, Backups dieser Transaktionen machen und er wäre abgesichert wenn der Channel zusammenbricht.
Was ist aber wenn der Sender in der Zwischenzeit die Bitcoinadresse, von der gesendet werden sollte, leert? Dann wären die Transaktionen die der Empfänger gesichert hat sinnlos geworden.
Da die Summe des Channel in der Blockchain mit einer zeitlichen Sperre versehen ist, kann der Sender erst nach Ablauf dieser Zeit oder durch Kooperation mit dem Empfängers über diese Summe, bzw. seinen restlichen Anteil daran, verfügen. Sagst du dass die Coins des Senders, die verschickt werden sollten, blockiert sind wenn er diese Transaktion erstellt hat und an den Empfänger weitergegeben hat?
Der gesammt mögliche Transaktionswert ist für die Lebenszeit eines Channel blockiert und wird erst mit der Glattstellung freigegeben. Die Glattstellung erfolgt dabei ausschliesslich in den vorgeplanten Grenzen. Also sind Transaktionen die erstellt wurden vom Sender, die aber vom Dritten nicht verifiziert wurden nicht dahingehend abgesichert dass der Sender die gleichen Bitcoins noch einmal verschicken kann bevor der Empfänger die Transaktionen glatt stellt?
Doch, da die gesammte Summe des Channel bis zur Glattstellung innerhalb der vereinbarten Grenzen gesperrt ist und über die Summe von keinem Geschäftspartner ohne Kooperation des Anderen verfügt werden kann. Ach der Sender besitzt die Bitcoins gar nicht mehr wenn er die Transaktion erstellt? Obwohl, selbst dann frage ich mich was passiert wenn der Empfänger nicht glatt stellt und der Sender versucht die selben Bitcoins an jemand anderen zu schicken. Und das müsste er ja tun können wenn dritte die Transaktion nicht verifizieren.
Mit der Öffnung eines Channel kontrollieren weder der Sender noch der Empfänger alleine das Geld. Das ist der übliche Multisig Mechanismus, der auch beim Multisig-Escrow zur Anwendung kommt. Kooperiert der Empfänger nicht oder verschwindet er, kann der Sender nach der vereinbarten Zeit das Geld komplett zurückbekommen. Der Empfänger hat hier also einen Anreiz zu kooperieren. Der Sender kann die BTC des Channel über die Lebenszeit eines Channel nicht ohne den Empfänger versenden. Der Empfänger kann nur den aktuellen Stand des Geschäfts kontrollieren und damit die Zahlungen, die er tatsächlich erhalten hat. Überweist er diesen Anteil, erhält der Sender automatisch den Restbetrag und der Channel ist geschlossen. |
|
|
|
... Außerdem, und das bedenkt keiner: "Wer hält den Private Key?" Der Azubi? Der Bankdirektor? Der IT-Admin? Es gibt noch keine informationstechnische Lösung zur Schlüsselverwaltung von Cryptowährungen durch Institutionen. Wer garantiert, dass nicht ein Mitarbeiter mit allen Keys abhaut bzw. die BTC heimlich um die Ecke bringt??? Bitcoin ist kein Buchgeld sondern echtes Geld, wenn das weg ist, ist es weg! Da helfen dann auch keine Bilanztricks mehr. Doch das gibt es schon. Stichwort: Shamir’s 2-of-3 Secret Sharing oder aber klassisches Multi Sig (BIP 11 oder BIP16). So kann ein Mitarbeiter mit einem Key abhauen aber das bringt ihm nichts. Das gibt es schon, aber wir reden hier über Banken! Die setzen so neumodisches Teufelszeug nicht von heute auf morgen um. In 50-100 Jahren vielleicht. Aber selbst dann ist Bitcoin immer noch ein System, welches sie nicht unter Kontrolle haben. Der Kurs hat nichts mit einem Einstieg der Banken in Bitcoin zu tun, da es diesen Einstieg einfach nicht gibt. |
|
|
|
Ich denke dezentral wäre eher wenn dritte die selben Transaktionen verifizieren könnten. Angenommen Geschäftspartner A zahlt Coins and B, dann geht die Transaktion verloren ohne glattgestellt zu werden. Einer hat ein Interesse daran dass sie verloren bleibt, der andere nicht. Aber beide haben keine unabhängigen Nodes die die Transaktion bestätigen könnten. Oder?
Warum sollte ein Dritter die Transaktion verifizieren müssen? A zahlt Coins an B. Sobald B die Zahlung aktzeptiert hat gibt es keine Möglichkeit für A, die Transaktion rückgängig zu machen. Das ist wie bei Bargeld. A bezahlt B. Sobald B das Geld bekommen und die Echtheit verifiziert hat kann A die Zahlung nicht mehr rückgängig machen. Deshalb ist diese Bargeld Transaktion von A an B doch noch lange nicht zentralisiert?! Wenn bei den Zwischentransaktionen nicht glatt gestellt wird, besteht dann nicht die Gefahr dass die Zwischentransaktionen verloren gehen?
Geht eine Zwischentransaktion verloren ist es, als ob sie niemals abgeschickt wurde. Sobald der Empfänger sie bekommt und er die Signatur verifiziert hat, kann der aktuelle Stand des Payment Channel vom Empfänger glattgestellt werden, indem er diese gültige Transaktion ins Bitcoin Netzwerk sendet. Damit wäre dieser Payment Channel dann geschlossen. Ach du meinst jede dieser LN-Transaktionen hat eine gültige Bitcointransaktion die der Empfänger notfalls in Bitcoinnetzwerk schicken könnte? Dann, solange der Empfänger diese Transaktion erstellen kann verliert er keine Coins?
Richtig. Es steht den Geschäftspartnern frei, den Zahlungskanal jederzeit zu schliessen und damit den den Saldo zu finalisieren. Solange der Kanal besteht können jedoch beliebige viele Transaktionen durchgeführt werden, die am Ende aber nur als Saldo in der Blockchain auftauchen. Man könnte es als eine Art Kompression betrachten. Ausserdem sinkt die Belastung des Bitcoin Netzwerk mit der Anzahl der Transaktionen pro Kanal deutlich. Daneben steigt die globale Transaktionsleistung des Bitcoin Netzwerk stark an, da durch diese kreative Art der Nutzung praktisch beliebig viele Off-Chain Transaktionen parallel durchgeführt werden können. Für die Transaktionen über den Kanal entfällt auch die Confirmation Time, da sie gesichert ist, sobald der Empfänger die Signatur erfolgreich verifiziert hat. Diese Off-Chain Transaktionen sind sozusagen der Geldaustausch. Verliert der Empfänger die letzte Transaktion und der Sender weigert sich, diese nochmal zu schicken, verliert der Empfänger das Geld. D.h. der Geldempfänger muss immer die letzte Transaktion speichern oder den Payment Channel schliessen.
Klingt riskant und für mich ist dezentral was anderes. Das wäre wenn 1000 andere Nodes wüssten dass die Transaktion stattgefunden hat und es kein "weigern" des Senders geben kann. Es kann auch ohne Dritte keine Weigerung des Senders geben. Hat der Sender eine gültige Transaktion an den Empfänger übergeben, hat er (fast) keine Möglichkeit mehr, diese Transaktion rückgängig zu machen. Er kann nur noch den aktuellen Transaktionsstand finalisieren und damit den Kanal schliessen. Anmerkung: Praktisch kann er natürlich den Empfänger umbringen, bevor dieser die Transaktion finalisiert. Oder er hackt die Rechner des Empfängers und löscht die Transaktion, bevor dieser sie finalisiert hat. Nein. LN ist eine Weiterentwicklung der Payment Channel. Damit können Transaktionen zusätzlich bidirektional durchgeführt werden und vor allem können Transaktionen sicher über Dritte geleitet werden. Damit können die LN Channels länger bestehen bleiben und es lassen sich Netzwerke von Geschäftsbeziehungen abbilden. Mit Webseiten hat das ganze überhaupt nichts zu tun, allerdings wird ein Protokoll entwickelt, um die Kommunikation zwischen den Geschäftspartnern zu standardisieren und vor allem zu abstrahieren. Während Payment Channel heute schon vollständig funktioniert, fehlen für LN noch ein paar Funktionen bei Bitcoin.
Diese Dritte könnten dann die Transaktion verifizieren als eine Art Escrow? Trotzem, eine weitere Partei ist nicht das selbe wie 1000e Nodes bei Bitcoin. Nein, die Dritten verifizieren dabei nur ihre eigenen Geschäftsverbindungen. Wenn sie nicht kooperieren, kommt keine Zahlung zwischen den eigentlichen Geschäftspartnern zustanden und das wissen diese beiden Geschäftspartner auch. In diesem Fall müssen sie sich einen anderen Weg für die geplante Zahlung suchen. Letztendlich verifizieren trotzdem die tausende Bitcoin Knoten das Geschäft. Nur eben nicht jede einzelne Zahlung, sondern den gesammten Prozess des Zahlungskanals. Damit ist dann sichergestellt, dass effektiv jede einzelne Zahlung über das Bitcoin Netzwerk abgesichert wird. Das ganze ist übrigens nicht komplett kostenlos: Damit das Bitcoin Netzwerk so einen Zahlungskanal absichern kann, muss die genutzte Summe an diesen Kanal gebunden werden. D.h. so ein Zahlungskanal hat einen Einfluss auf die Liquidität. Möchte ich nächstes Jahr 100 Einkäufe im Gesammtwert von 2 BTC über einen solchen Zahlungskanal abwickeln, muss ich diese 2 BTC besitzen und sperren. Habe ich die 2 BTC (noch) nicht, muss ich die Geschäfte zeitlich gestaffelt in mehrere Zahlungskanäle aufteilen. |
|
|
|
... Schweiz ...
Die Schweizer möchten gar keine Deutschen haben, auch nicht wenn die dort arbeiten und Steuern zahlen. Maximal als zahlende Tourist sind die dort geduldet. |
|
|
|
aber das ist keine hexenjagd einfach n paar info´s zu der person der ich wahrscheinlich im dez 500 euro überweisen werde,
Gibt es hier einen kopfschüttelnden Smiley oder einen Face-Palm Smiley?! |
|
|
|
Hurra, bald bin ich auch Flüchtling!
Freu Dich nicht zu früh. Anderen Länder fragen erst mal was Du ihnen bringst. Fällt die Antwort nicht nach deren Interesse aus, bekommst Du maximal ein Touristenvisum. Und das auch nur, wenn Du genug Geld mitbringst um sicher Deinen Lebensunterhalt zu finanzieren. Als gesunder Handwerker oder Ingenieur dürfte es aber nicht allzu schwer werden, ein aufnahmebereites Land zu finden. Wenn Du ignorierst, dass die meisten Länder ihre eigenen Probleme haben, die teilweise noch gravierender sind als bei uns, dann lässt es sich da ganz gut leben. |
|
|
|
|
Du weisst aber schon, dass der Denic Eintrag nicht von Dir veröffentlicht werden darf?!
Allerdings kann das ja jeder selbst bei Denic nachprüfen.
|
|
|
|
Zum Glück kann uns hier nichts passieren, was in Paris passiert ist, weil wir so gut sind! Wir sorgen gut für die und solange die zufrieden sind, gibt es auch keinen Grund für Terror.
Da gibt es keinen kausalen Zusammenhang. Such mal nach Christian Emde. |
|
|
|
|
Show Posts
