joho

Wenn du das Geld verkraften kannst, ist eine Hardwarewallet die einfachste und sicherste Methode die Bitcoins sicher aufzubewahren. Das Backup besteht aus 12-24 Wörtern, die du wie eine Paperwallet sicher verwahren solltest. Der Vorteil ist, dass du problemlos mal eben Bitcoin verschicken kannst, ohne dass du deine Schlüssel kompromittierst. Auch kannst du das Paperbackup per Hand schreiben, sodass du nicht einem Drucker vertrauen musst. Paperwallet ist prinzipiell recht sicher, wenn du ein paar Vorkehrungen bei der Erstellung triffst (möglichst offline, am besten TAILS oder ähnliches benutzen, eigenen Drucker benutzen). Wenn du sie ausgibst, musst du dann den Rest auf eine neue Paperwallet schieben, denn die alte hast du ja mit der Eingabe des private keys "verbrannt". Cold Storage ist nicht mehr Cold Storage, wenn du ihn auf einem normalen Desktop liegen hast, den du online benutzt. Mit einem sehr sicheren Passwort kann das ganze zwar sicher sein, aber nur solange du das Passwort nie eingibst , Multisig habe ich noch nicht richtig probiert. Es ist ein wenig aufwändiger, weil du die Transaktionen zwischen den beiden Rechnern hin- und herschieben musst. Außerdem kosten multisig Transaktionen gleich fast doppelt soviel Gebühren (solange SegWit nicht da ist). Es ist einigermaßen sicher, solange du auf Desktop and Laptop nicht den gleichen Trojaner installierst

Ist der Absender 1Sochi oder 1Enjoy? Ich habe auf meiner uralten Electrumwallet (letzte Benutzung 2014) vier solche Transaktionen im März bekommen. Kann man nur ignorieren. Nichteinmal geschenkt würden die Miner die nehmen (also mit 100% fee). D.h. dieser Spam ist jetzt wohl auf Ewigkeit teil des UTXOsets (unverbrauchte Ausgänge) den alle Fullnodes im Hauptspeicher halten. Ein Satoshi (0.00000001 BTC) ist der kleinstmögliche Betrag und eigentlich sollte jeder Miner eine Transaktion, die solchen Müll produziert zurückweisen. Leider halten sich nicht alle Miner daran.

@cptpxl: Wie groß sind die Transaktionen (siehe blockchain.info)? Wenn die 0.04 oder 0.002 vom Kumpel riesige Transaktionen mit zu geringer Gebühr sind, kann es sein, dass selbst die 5 Euro nicht ausreichen. Am Wochenende wird wahrscheinlich wieder etwas Backlog abgebaut. Vielleicht hast du ja Glück.

Die Gebühren für beide Transaktionen sind zu gering. Im Moment liegen immer noch 50000 Transaktionen seit einer Woche im backlog, die das doppelte zahlen und trotzdem nicht genug. Deine Transaktion war zwischendurch verschwunden, weil sie aus dem Mempool gefallen ist. Wenn der voll ist, werden nämlich die Transaktionen mit den geringsten Gebühren gelöscht. Allerdings löschen nicht alle gleichzeitig und ein paar kennen jetzt die eine, und ein paar die andere. Du kannst demnächst probieren nochmal zu senden, wenn die Transaktion wieder verschwindet, dann aber mit mindestens der vierfachen Gebühr. Im Moment wird 300 sat/byte empfohlen, also das fünf bis sechsfache. Der Blockspace ist knapp und zu viele Leute wollen Transaktionen senden. Nur wer mehr zahlt als die anderen hat eine Chance. Vielleicht funktioniert jetzt auch ViaBTC accelerator mit einer der beiden Transaktionen. Tipp: Immer zur vollen Stunde probieren, die verfügbaren slots sind dann aber innerhalb einer Minute weg.

Bei ~1 sat/byte ist double-spend gar kein Problem. Du musst nur den Bitcoin core client dazu bringen die Transaktion zu vergessen (ich glaube neuere Versionen von bitcoin core haben dafür eine Option "abandon transaction" oder mit -zapwallettxes starten). Alle anderen Nodes sollten die Transaktion gar nicht in ihrem mempool haben, da die Gebühren viel zu gering sind. Bei 100 sat/byte wäre es deutlich schwieriger, denn dann kennen die Nodes die Transaktion und weigern sich double-spends aufzunehmen. Dann muss man es öfter probieren. Nach 3-14 Tagen vergessen Nodes üblicherweise eine Transaktion, aber es gibt Nodes, die regelmäßig fremde Transaktionen wiederholen, sodass in der Praxis sie nie wirklich vergessen werden. Dann würde allerdings ViaBTC's accelerator funktionieren.

Bei bitcoin.de geht das Fiat-Geld doch von den Käufern direkt auf dein Bankkonto. Ob du aber 25000 auf einmal traden kannst hängt ja auch davon ab, ob es dafür einen Käufer gibt.

Wenn du von einer Börse sendest, wählt die Börse die Transaktionsgebühr. Vielleicht hat sie auch Verträge mit Minern, oder die Transaktion ging gar nicht über die Blockchain. Im Moment bekommt man bei weniger als 25 cent Gebühren im Bitcoinnetzwerk nicht einmal eine Wartenummer. Die Transaktion wird einfach zurückgewiesen.

Das ist Angebot und Nachfrage. Vor zwei Jahren hatte jemand mal vorgeschlagen, das Angebot zu erhöhen, ist aber auf zu großen Widerstand der Bitcoingemeinde gestoßen. Wahrscheinlich weil die sich nicht vorstellen konnten, dass das überhaupt nötig ist. Aber der andere Grund war dass man einen "gesunden Gebührenmarkt" wollte und bei zu viel Angebot (die Kosten, die die Miner haben um Transaktionen aufzunehmen sind minimal) gehen die Preise in den Keller. Jetzt ist die Nachfrage ein klein wenig größer (5-10 %) als das Angebot und die Leute überbieten sich gegenseitig, um den Minern die Gebühren hinterherzuwerfen. Ändern kann man daran kurzfristig nichts und langfristig will jeder eine andere Strategie fahren und sich auf keinen Kompromiss einlassen. Die Miner freuen sich natürlich über die Gebühren, aber die meisten würden auch deutlich weniger akzeptieren. Aber wenn du nur ein Ei verkaufen darfst und einer bietet dir 1 Euro und der andere 10 Euro, wem verkaufst du dann das Ei?

Mit Gebühren kenne ich mich aus Es ist so, dass du in Bitcoin, wenn du die empfangenen Bitcoins verschicken willst, jede Zahlung einzeln unterschreiben musst. Das liegt daran dass Bitcoin keine Konten kennt, sondern nur die Zahlungen speichert und verlinkt. Unterschriften brauchen Platz auf der Blockchain und der kostet Gebühren. Im Grunde musst du also für jeden Empfang eine Gebühr zahlen, nur dass du die erst siehst, wenn du das Geld weiterverschicken willst. Es waren mal 1 cent pro Eingang (empfangener Zahlung), im Moment sind es 80 cent regulär (edit: naja bitcoinfees.21 schlägt eher 100 cent vor, aber so eilig habe ich es dann nie) oder 35 cent super-Wochenendsondertarif (122 sat/byte oder 1.22mBTC/kB; auf keinen Fall tiefer). Bei mycelium kannst du die Eingänge zählen, unter Konten auf das Konto kllicken, "..." und Zeige noch nicht ausgegebene Outputs. Dann kannst du selbst ausrechnen, ob sich das überhaupt lohnt. Es kann sein, dass sich alles wieder etwas beruhigt, Im März ist es schon einmal passiert, dass selbst zum Wochenende die Gebühren nicht gefallen sind, aber im April konnte man dann an ein/zwei Wochenenden fast jede Transaktion bestätigt bekommen (ein halber Cent pro Eingang war kein Problem). Allerdings ist im April auch der Kurs deutlich gefallen. Aber bevor du 90 % Gebühren zahlst lohnt sich Warten.

Die brainwallet hatte ein paar nützlich Operationen. Die Seite wurde eingestellt, weil brainwallets inzwischen als viel zu unsicher gelten, aber man kann einen Klon verwenden, z.B. https://brainwalletx.github.io/ oder https://sipak.github.io/brainwallet/ Die Seite sollte keine Keys an den Server senden. Trotzdem würde ich sie nicht unbedingt mit wichtigen Keys benutzen. Man kann dort private key im WIF-Format oder als Hex-Zahl (secret exponent) eingeben und bekommt den Public Key und die Adresse, wobei man noch auswählen kann, ob compressed oder uncompressed.

Ich habe mal mein Programm auf gist.github gelegt: https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89 Es ist ein wenig buggy, z.B. wenn der private key mit zu vielen Nullen endet Auch fängt es false positives nicht ab und gibt dann eventuell den falschen Key aus. Es ist ein quick hack und das erste Mal, dass ich libsecp256k1 benutze. Es gibt viel Verbesserungspotential: fe_inv_all_var statt fe_inv_var benutzen parallelisierung der beiden Schleifen man kann sich ein gej_add_ge_var sparen, wenn man sich auf einen public key konzentriert. eventuell bessere Hashtabellenimplementierung

Genau gesagt ECDLP mit der Babystep-Giantstep Methode. Für #52 würde es ca. 12 Minuten und 1GB Speicher brauchen. Die zwei Fällle ergeben sich, weil ich das Vorzeichen des Babysteps nicht überprüfe (baue ich vielleicht später ein). Aber ob ich 20 Minuten response-time schaffe ist unwahrscheinlich Nur wenn ich zufällig online bin, die Nachricht rechtzeitig sehe und den Laptop bereit habe. Es ist schade, dass die Puzzle-Transaktion nicht pay to pubkey outputs benutzt, sondern hashes. Andererseits wäre sie dann aber wahrscheinlich schon längst bis ca. #80 geleert.

Wenn ihr #52 gefunden habt, kannst du ja mal den public key (im Format "028c6c67bef9e9eebe6a513272e50c230f0f91ed560c37bc9b033241ff6c3be78f") schicken, ohne den private key zu verraten. Ich würde gerne mein kleines C-Programm testen: >time ./a.out Found private key 2: fffffffffffffffd or 3 Found private key 3: fffffffffffffff9 or 7 Found private key 4: fffffffffffffff8 or 8 ... Found private key 48: ade6d7ce3b9b or ade6d831c465 Found private key 49: 174176b015f4d or 174176cfea0b3 Found private key 50: 22bd43bd16cac or 22bd43c2e9354 Found private key 51: 750709e5ff62c or 75070a1a009d4 real 8m34.117s user 8m32.756s sys 0m1.092s Nein, keine Monstermaschine, nur mein zwei Jahre alter Laptop mit Core-i5 Prozessor und ohne angeschlossenes Netzteil. Das Programm funktioniert aber leider nur, wenn man den public key hat, der hash reicht nicht .

Speichern ist nicht nötig, siehe https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012204.html Benötigt 4-fachen Rechenaufwand, aber dafür nur ein paar 100 byte Speicher. nicht parallelisierbar: Das ist zwar richtig, aber mit Parallelisierung wird es nicht 2^53-mal schneller, außer jede Person auf dem Erdball lässt das Programm auf einer Millionen Cores parallel laufen. Es gibt auf jeden Fall einen guten Anhaltspunkt über die Kosten für 2^86 Hashes. Da die Miner einen Umsatz von derzeit 630'000 Bitcoin im Jahr machen, können wir grob sagen, dass es mehrere 100'000 Bitcoin kostet so viele Hashes zu berechnen. Public Keys zu berechnen ist zwar 100-1000 mal auwändiger, aber das lassen wir mal kurz außer acht. Wenn man jetzt interessiert ist fremde Bitcoins zu stehlen, indem man Addressen zu privaten Schlüssel berechnet und schaut, ob die Addresse Bitcoins enthält, dann ist es für den durchschnittlichen Gewinn unerheblich, ob alle Bitcoins auf einer Adresse liegen, oder jeder Satoshi auf einer anderen. In beiden Fällen ist der Erwartungswert weniger als 21'000'000 Bitcoin pro 2^160 Hashes, oder mit der gesamten Hashpower aller Miner 0.0000001 Satoshi pro Jahr (wenn Moore's Law anhält und die Miningpower weiter steigt, sind es in 5 Jahren vielleicht 0.0001 Satoshi pro Jahr). Diese Zahlen sollten deutlich zeigen, dass alle "Kollisionen", die bisher gefunden wurden auf unsicheren Schlüsseln beruhen und keine echten Kollisionen sind. Der originale private Schlüssel stimmt mit dem gefunden Schlüssel überein. Ich weiß jetzt nicht wie du auf jetzt auf 1 zu (2^96)^2 kommst, aber die Wahrscheinlichkeit, dass jemand einen 50 bit langen Private-Key erzeugt hat, ist deutlich größer als dass jemand einen zufälligen Private Key erzeugt hat und es eine Kollision mit einem 50 bit langem Schlüssel gibt. Die Wahrscheinlichkeit, dass es zu einem zufällligen Schlüssel einen 50 bit langen Schlüssel mit dem selben Hash gibt ist leicht zu berechnen: Eins zu 2^110 und damit kleiner als die Wahrscheinlichkeit, dass 5 Wochen lang jeden Mittwoch die gleichen Lottozahlen mit der gleichen Superzahl gezogen werden.

Es geht bei LBC nicht um eine Kollisionsattacke, sondern eine Preimage-Attacke. Auch wenn der Name anderes vermuten lässt. Bei einer Kollisionsattacke erzeugt man 2^80 Schlüssel und schaut dann, ob man zweimal den gleichen Public Key hat. Aufgrund des Geburtstagsparadoxons ist die Wahrscheinlichkeit dafür recht hoch. Nur bringt einem das nichts, weil man dann lediglich eine Addresse hat, für die man zwei verschiedene Schlüssel hat. Man muss immer noch jemanden dazu überreden sie auch mit Bitcoins zu füllen Bei multisig-Addressen kann das problematisch sein, denn wenn Malleroy eine Kollision für eine Multisig-Adresse berechnet kann man Malleroy Alice davon überzeugen, dass die Addresse mit Alices Key gesichert ist, aber Malleroy hat noch einen Zweitschlüssel, der Alices Key nicht benötigt. Daher wird segwit die Multisig-Addressen auf 256 bit erweitern, um 128 bit Security zu bekommen. Hier versucht aber jemand eine der existierenden 100 Millionen Bitcoin-Addressen zu treffen. Dazu muss man aber im Mittel 2^160/10^8 ~= 2^133 Schlüssel ausprobieren. Das ist schwieriger als die Public Keys mit dem altbekannten Giant-step-little-step Verfahren zu knacken. Elliptische Kurven mit 256 bit haben nur 128 bit Security. Die Exponential-Funktion ist teuflisch, eine Erhöhung des Exponenten um 10 macht das ganze 1000 mal aufwändiger. Das Bitcoin-Netzwerk kann mit seiner gesamten Mining Power ca. 2^83 Hashes im Jahr durchprobieren. Für 2^133 Hashes würde es aber eine Billiarde Jahre brauchen, das ist 100'000 mal länger als das geschätze Alter des Universums.

Dann musst du auch nichts verschieben. Es ist lediglich die neue Wallet nicht vollständig synchronisiert. Was sagt das Netzwerk-Icon unten rechts in der Statuszeile, rot, grün oder blaues Reload-Symbol? Wenn du da klickst, öffnet sich ein Dialog in dem du einen anderen Server wählen kannst. Es hilft auch manchmal die uralte Methode, beenden und neustarten. Oder auch nochmal alles von vorne und eine neue Wallet mit dem gleichen Seed erstellen.

Heute (Sonntag) kannst du die Fees wohl problemlos um Faktor 100 verkleinern; 1 sat/B geht im Moment einigermaßen schnell durch, dass sind etwa 150 satoshi pro eingehende Zahlung. Mehr als 500 eingehende Zahlungen sollten es aber nicht sein, sonst wird die Transaktion zu groß (deswegen hast du die Fehlermeldung bekommen, dass du zuviele unspent inputs hast). Du brauchst nicht unbedingt eine neue Adresse zu kreieren, an die du sendest. Es ist angenehmer, denn wenn die Transaktion im Limbo ist, ist dann wenigstens egal, ob sie irgendwann durchgeht oder nicht. Aber wenn du direkt an bitcoin.de schickst, sollten die Bitcoins trotzdem irgendwann gutgeschrieben werden, selbst wenn die Zahlung zwei Wochen braucht um bestätigt zu werden. Wichtig ist wohl auf "Advanced Send" zu klicken, dass du die Gebühr selbst wählen kannst. Ich habe das jetzt aber nicht ausprobiert. Nicht Kleinstbeträge sind gemeint, sondern kleinere Beträge, die noch nicht zu der Fehlermeldung führen, in deinem Fall also wohl 100 $.

Viele der Angebote sind nur für Expresskäufer, d.h. du musst dann eventuell das ungünstigere Angebot nehmen (oder selbst ein Angebot einstellen). Ansonsten besteht beim Kauf nie die Gefahr, dass der Verkäufer nachträglich ablehnt, sofern du die Überweisung rechtzeitig, vom richtigen Konto, und mit der richtigen Trade-ID tätigst. In dem Moment in dem man ein Verkaufsangebot einsetzt, sind die Bitcoins gesperrt und der Verkäufer kann sie nicht abziehen. Beim Verkauf ist das anders, denn der Käufer könnte ja einfach keine Überweisung veranlassen, und dann musst du hinterherrennen, wenn du auf den Verkauf bestehen willst. Expresskauf hat geringere Gebühren als manuelle Überweisung, was witzigerweise bei der Gebührenstruktur dazu führt, dass du mehr bezahlst, aber dafür auch mehr bekommst. Aber Gebühren fallen auf jeden Fall an, sie sind aber unter 1 %.

Heute wurde der mempool noch weiter abgebaut. Nur noch knapp 3 MB übrig und alles unter 1.2 sat/B. Eventuell gehen heute noch die Transaktionen ganz aus. Einige Pools produzieren schon kleinere Blöcke. Der Gebührendruck ist aber weiter hoch und gestern nachmittag/abend gab es wieder einen backlog von über 12 Stunden für 100 sat/byte Transaktionen. Siehe auch https://jochen-hoenicke.de/queue/2d.html (Leider ist gestern der Server um 17 Uhr ausgefallen, daher fehlt ein Stück und viele Transaktionen im Mempool sind verlorengegangen)

Nein, seit Ende Januar ist 50 satoshi/B oder 0,0005 bitcoin/kb die "wenn nicht heute, dann vielleicht morgen oder übermorgen" fee. Für drei Stunden bis zur Bestätigung definitiv zu wenig. Empfohlen wird inzwischen über 200 sat/byte, Sparfüchse können aber auf 125 satoshi/B runtergehen, wenn ein paar Stunden nicht stören. Tiefer würde ich nicht gehen, da es sehr viele Transaktionen mit 120 gibt. Ich habe schon Transaktionen mit 100 sat/B gesehen, die mehr als 24 Stunden brauchten. Wenn man keinen Wert auf schnelle Bestätigung legt, kann man aber im Moment auch auf unter 5 satoshi/B gehen. Sollte eigentlich morgen irgendwann bestätigen, wenn der aktuelle Crash nicht weiter für so viel Traffic sorgt, oder deswegen die alten stromfressendsten Miner abgestellt werden.

Hi, meine Antwort ist spät, aber vielleicht besser als gar nicht Die Wallet von ether.li ist eine contract wallet, d.h. es ist keine einfache Adresse, sondern sie führt etwas Code aus. Daher benötigen eingehende Transaktionen etwas mehr Gas als Transaktionen an einfache Adressen. Das Gas muss der Sender bezahlen und er muss das maximal auszugebende Gas anpassen. Viele Wallets berechnen das Gas automatisch. Hier ist aber etwas schiefgelaufen (z.B. der Sender hatte seine Wallet nicht gesynct, oder er hat manuell zu wenig Gas eingestellt). Er hat 21000 Gas mitgegeben, 22542 braucht aber die Wallet mindestens. Beim nächsten Mal besser 30000 mitgeben, überschüssiges wird zurückgegeben. Die Transaktion ist jetzt fehlgeschlagen, d.h. das Geld ist immer noch beim Sender und das Gas ist weg (vom Miner einkassiert). Um die Transaktion erneut zu senden, braucht es eine neue Unterschrift vom Sender. Außerdem sollte er diesmal genug Gas mitgeben. Du kannst ja aus Fairnessgründen anbieten, dass er die zu erwartende Überweisungsgebühr (Gas * Gaspreis, ca. 0.0005 ETH) von den 10 ETH abzieht.

Ein Fall für diese Liste http://what-if.xkcd.com/146/ Wenn es passiert, verlierst Du deine Bitcoins an einer Adresse. Sagen wir, du hast 100 BTC. Wahrscheinlichkeit, dass man etwas stiehlt ist 2^-160 pro ausprobierter Addresse. Sagen wir es werden pro Jahr ca. 1 Trillionen Addressen (100 Millionen pro Person) ausprobiert und mit der Blockchain abgeglichen. Dann verlierst du in 100 Jahren im Mittel ca. 100*10^8* 10^18 * 100/2^160 = 0.0000000000000000007 Satoshi. Du kannst das Risiko minimieren, indem du auf jeder Adresse nur 1 BTC speicherst, damit im Fall der Fälle nur ein Bruchteil deines Vermögens weg ist. Und dann solltest du auch bei jedem Gullideckel nachprüfen, ob er nicht nur ein Hologramm ist

Die Technologie von zcash (zk-Snarks) ist schon sehr interessant. Ich habe mich jetzt durch das Pinocchio-Paper (nearly practical verifiable computation) gearbeitet und so langsam verstehe ich wie es funktioniert. Es ist meiner Meinung zur Zeit etwas zu stark gehypet. Der Startkurs war ja jenseits von Gut und Böse. Wenn sich keine schwerwiegenden Bugs finden, ist es schon auf lange Sicht interessant (die Bitcoin-Blockchain ist einfach zu geschwätzig). Aber es ist noch bleeding-edge Technologie. Ein Fehler im Protokoll und die zcash können über Nacht wertlos werden, da man nur schwer nachweisen kann, ob jemand betrogen hat. Es fehlt auch noch die Infrastruktur. Wenn man versteckte Transaktionen mit Hardware-Wallets durchführen will hat man eine größere Herausforderung. Der Evaluation-Key (public key für die Erzeugung von "Unterschriften") ist 900 MB groß und auch der Rechenaufwand ist riesig im Vergleich zu einfachen Bitcoin-Unterschriften. Außerdem gibt es inzwischen die deutlich einfachere Idee "MimbleWimble". Die Idee ist, dass man die Transaktionen gar nicht dauerhaft speichern muss, was die Privatsphäre erhöht. Das ist zwar nicht ganz so privat (falls jemand doch alle Transaktionen speichert). Aber es hat weiterer Vorteile hat, z.B. eine deutlich kleinere Blockchain. Auch hier gibt es Nachteile (z.B. dass man bei MimbleWimble einen Private Key braucht, um Geld zu empfangen) und die UTXO brauchen deutlich mehr Speicher (aber jeder braucht im Grunde nur noch eine UTXO auf der Blockchain).

Warum man die eindeutige Absenderadresse braucht, ist mir noch nicht klar. Wenn der Auftragnehmer eine eindeutige Sende-Adresse hat, die für jeden Kunden/Auftrag anders ist, dann kann man die Zahlungen ja auch an der Zieladresse erkennen, bzw. auch im BlockExplorer alle Zahlungen sehen, wenn man die entsprechende Adresse öffnet. Okay, der Auftragnehmer kann dann nicht sehen, ob der Kunde die Summe in seiner Wallet hat. Wenn du wirklich die Absenderadresse wählen willst, geht das auch. Mit electrum kann man sie einfach unter Adressen wählen und dann rechts-klicken und "Senden von" wählen. Wenn dort nicht genügend Geld ist, muss man natürlich vorher etwas auf die Adresse überweisen. Bei einer Multisig-Wallet haben beide Partner eine gemeinsame Wallet mit mehreren Adressen, in der sie alle eingehenden und ausgehenden Zahlungen sehen. Zum Einzahlen in die Wallet kann man dann einfach an eine der Empfangsadressen von einer anderen Wallet überweisen. Zum Auszahlen erstellt dann einer der Partner die Transaktion, unterschreibt sie und schickt sie an den Partner. Der kann die dann laden, ebenfalls unterschreiben und dann kann sie erst ausgeführt werden. Man kann aber auch andere Modi einstellen, z.B. bei 1 von 2 multisig kann jeder der beiden Auszahlungen vornehmen, ohne dass der andere sie unterschreiben muss. Oder es gibt 2 von 3 multisig mit drei Partnern, z.B. einem Treuhändler und zwei Geschäftspartnern, bei denen dann jeweils zwei Unterschriften zum Überweisen notwendig sind. Einfach mal ausprobieren, am besten mit kleinen Beträgen...

Wenn man weiß, wie es geht, ist es gar nicht so kompliziert. Zu 1. kann man einfach sich selbst an seine Adresse Geld überweisen; das geht auch von der gleichen Wallet. Ob das so sinnvoll ist, ist eine andere Frage, denn eigentlich gibt es bei Bitcoin keine Sendeadresse. Es ist oft nicht garantiert, z.B., bei Internetwallets, dass die "Absenderadresse" wirklich dem Absender gehört. Das Feld unter Empfangen ist dazu gedacht von anderen Geld anzufordern. Dort kann man auch den Zahlungen Namen geben, damit man nicht aus Versehen zwei Leuten die gleiche Adresse gibt und man hinterher zuordnen kann, von wem das Geld kommt. Zu 2., eventuell Expertenmodus anstellen (gibt es den noch?), dann unter Adressen die Adressen auswählen, (mit Ctrl kann man mehrere Adressen wählen), dann rechte Maustaste "Senden von". Man gelangt zum Senden-Tab und es sind die auszugebenen Coins (empfangene Zahlungen) voreingetragen. Dort dann nur noch den gewünschten Betrag und die Zieladresse eintragen, fertig. Will man alles senden, genügt ein "!" im Betragsfeld. Gebühr wird automatisch berechnet. Wenn man denkt, man kann die benötigte Gebühr besser selbst abschätzen, kann man die Gebühr aber noch ändern.