ähm ja. das ist der gleiche key, bloss in einem anderen format.
aber du kannst ruhig aufhören, dich zu winden. ich werde dem geld nicht hinterherlaufen. bei mir bist du damit halt komplett unten durch. solche sprüche bringt man einfach nicht, wenn man nicht auch in der lage ist, im zweifelsfall auch dafür gerade zu stehen.

natürlich kann man das eine fehlinterpretation nennen. gerade um das zu vermeiden, benutzt man ja normalerweise auch nicht den private key direkt, sondern das wallet import format. letztlich muss aber immer irgendwo mitgespeichert werden, ob der private key nun einen komprimierten public key hat oder nicht. der private key alleine ist nicht eindeutig. letztlich wurde mit den compressed public keys die eindeutigkeit private key -> adresse aufgegeben.

bin gerade nicht sicher, ob ich die frage richtig verstehe. prinzipiell kann man beide adressen gleichzeitig nutzen, bei meinen blockchain.info wallet wäre das jetzt z.b. der fall.



ach candoo, da du im nachhinein dein post editiert hast, fühle ich mich wohl doch genötigt, den scammer-tag zu beantragen. geht mir gar nicht um die 1000€, mir war eigentlich schon vorher klar, dass du die aussage wohl einfach nur mal so rausgegehauen hast. aber die reaktion finde ich dann eben doch schon sehr fragwürdig, gerade für jemanden, dem andere leute etliche tausend euro anvertrauen.

"5KTh19mkG2w85QWZRawRntfaURp7qBcVf5jE8AATdvXzKVkfzht" enthält wie gesagt die information, dass der key uncompressed ist. dass ""FacopAA6v9N5o9U95HVBhGdbqJWrpUGjBq1K5D61YEYm" auch gleich als diese adresse interpretiert wird, ist eigentlich voreilig und führt bei frisch generierten keys von neueren clients zu einer falschen adresse.

so, die importier ich jetzt in ein blockchain.info wallet. da kriegt man dann unter "export unencrypted" folgende ausgabe:

da sieht man dann schonmal, wie der private key tatsächlich aussieht. das wallet import format enthält zusätzlich informationen, die angeben, dass der key uncompressed ist. das sieht man schon an der "5" am anfang.

dann nehm ich den private key - immer noch im wallet import format - paste ihn bei brainwallet.org rein, wechsel auf compressed, importier den key im wallet import format, den ich da rauskriege, wiederum bei blockchain.info.

ergebnis sieht so aus:



wie du siehst, zwei mal der gleiche private key, zwei verschiedene adressen.
und danke für die großzügige bounty. 1000€ kann ich gerade ganz gut gebrauchen  

edit: ach, ganz vergessen. falls du doch lieber in bitcoin zahlst: 1MqUMujuZp5bWhjYbGAhJqPVNSMdmxSZuM


 

beispiel: https://github.com/spesmilo/electrum/issues/27

wenn du deinen private key irgendwo importierst, ohne zu wissen, ob der public key komprimiert oder unkomprimiert war, kommt evtl. die andere, "falsche" adresse dabei raus.

das ist so nicht richtig. normalerweise stellt es sich für den nutzer so dar, als würden adresse und private key ein untrennbares paar bilden. tatsächlich ist die zuordnung weder in die eine noch in die andere richtung eindeutig.

unterschiedliche private keys können gleiche adressen erzeugen, die wahrscheinlichkeit ist aber so gering, dass sie keine rolle spielt. (müsste der wahrscheinlichkeit einer hashkollision in ripemd-160 entsprechen, genauen wert kannst du selber nachgucken  )
außerdem kann ein private key auch mehrere adressen haben. die adresse wird über den umweg des public keys erzeugt, bei bitcoin-qt wurden beispielsweise zwischenzeitig komprimierte public keys eingeführt, um platz in der blockchain zu sparen. beim komprimieren ändert sich aber der hash und damit die zugehörige adresse. es gab schon fälle, wo nach irgendwelchen adress-import-export-exzessen bitcoin-qt anschließend von der falschen adresse ausgegegangen ist und walletinhalte dann nicht mehr korrekt angezeigt wurden.

der user revalin hat kürzlich ein paar scripte für spezialisiertere fälle geschrieben.

guck dir mal seine jüngeren posts an:
https://bitcointalk.org/index.php?action=profile;u=39897;sa=showPosts

die scripte sind eigentlich einfach genug, dass du selbst ein bisschen damit rumspielen kannst, wenn du dich noch an den ungefähren aufbau deines passwortes erinnerst.

+1

ich habe mehrere gutscheine gekauft. verkäufer hat aus versehen auch einen schon verbrauchten dabei gehabt, aber innerhalb weniger minuten einen neuen geschickt. insgesamt schnell und unkompliziert, kann ich weiterempfehlen.
die gutscheine, die ich gekriegt habe sind übrigens bis ende 2016 gültig.

i am well aware of that. as i said it limits the best case scenario. but if we really do hit 5mb in say summer or fall 2014 that also means bitcoin is twenty times as big as it is now. imho, at that point its likely too big to fail - pun intended.
so i would like to intentionally sacrifice the best case to avoid the worst case. short term at least.

i agree with mike that staying with the 1mb limit is far more radical - and unreasonable - than increasing block sizes. however, i think there is little need to find a final solution at this point. a conservative increase of the max block size - for example to 5mb - is a very simple and predictable short term solution. 5mb would work on computers and bandwidth a lot of people already have so you dont even have to argue with moores law or anything to show that you wont run into trouble.
and when the exponential growth hits that new limit hard and fast and there are still lots and lots of full nodes around, the 1mb-extremists will be very very quite and it will be much easier to get a consent on something more final  

there might be more elegant solutions, but pushing for anything that might even remotely look like it wont run on an already existing, affordable consumer computer is a very hard sell. at least for now.

ps: mike, i think you have trouble grasping how alien exponential growth is for pretty much everyone. it eludes the natural human capability to make good estimates and seems overwhelming and scary. psychologically, predictability is extremly important right now and thats one of the main reasons i advocate for a fixed increase in block size for the time being. i think its worth limiting the best case scenario for short term bitcoin growth for that.

etwas weniger geheimhaltung, was deine firma überhaupt für bitcoin anbietet, wäre den umsätzen sicher auch nicht abträglich 
hast du schon schon ein posting für das service announcement forum vorbereitet?

you dont. armory was on kickstarter.

genau so ist das. 75gb, so ein unsinn. das sind 5 br-filme oder 5 spiele bei steam. pro monat, und nix sonst. wirds mit sicherheit niemals geben. effektiv wird auch bei 500gb blockchain-zuwachs pro jahr bitcoin bei intensiveren internetnutzern <10% des gesamten downloadvolumens stellen.
das gegenteil ist aber auch blödsinn. wenn z.b. mike hearn sagt, lass uns doch x-tausend transaktionen pro sekunde zulassen, nächste woche hat doch eh jeder glasfaser und moores gesetz wird es schon richten, ist das eben auch ziemliche hurra-planung. moores gesetz kann jederzeit in den vorderpfoten zusammenbrechen und dann steht man dumm da. deshalb bin ich auch für größenordnungen, die heutige rechner und netzwerke gut auslasten aber eben auch nicht mehr. wie die festplatten, cpus und bandbreiten in der zukunft aussehen, weiss in wirklichkeit niemand. es gibt überhaupt keinen grund, da jetzt schon eine finale entscheidung zu treffen.

eine moderat größere blockchain können durchaus noch sehr viele desktoprechner mit üblicher anbindung verarbeiten. z.b. 5mb pro block = max 250gb pro jahr ist gar kein problem. das lädt man in einer woche mit 16mbit runter und die blockchain wächst dann auch immer noch bequem langsamer als die festplatten. reicht ja, wenn viele die blockchain haben können, jeder c64 in hinterpümpelheim ist gar nicht nötig.
ob tatsächlich beliebige blockgrößen machbar und sinnvoll sind, ist eine diskussion, die man in ein paar jahren führen kann.
die ganzen "1mb-forever"-fanatiker genauso wie die "wir brauchen den freien market"-sektierer sind doch größtenteils nur damit beschäftigt, ihren mitmenschen auf den keks zu gehen. mit pragmatischen lösungen hat das wenig zu tun.

ganz viel testnet und mehrere clients kann man sich ja wünschen, aber man muss auch mal realstisch sehen, dass sowas zeit und geld braucht. ein paar leute arbeiten schon dran, matt corallo bei bitcoinj und alan reiner mit armory zum beispiel. alan reiner hat auch schonmal einen spendenaufruf gemacht, damit er sich mehr auf die entwicklung von armory konzentrieren kann, da kamen aber nur 4000$ von den erhofften 12000$ zusammen. bei den heutigen kursen wäre das vielleicht schon anders. wer sich einen zweiten vollwertigen client wünscht und das entsprechende kleingeld jetzt zur verfügung hat durch die kursanstiege, sollte eine spende vielleicht in erwägung ziehen.
die foundation hat jetzt auch plötzlich viel mehr geld zur verfügung, ein bisschen was wurde schon ins testnet investiert. aber da werden sicher noch ein paar investionen getätigt, einen QA-manager wünscht sich gavin schon seit längerem.

und inwiefern soll diese geisteshaltung mehr sinn machen?
wenn niemand bitcoin hat aka "spekuliert", wird bitcoin nie genutzt werden können. also entweder du hälst bitcoin prinzipiell für scheisse oder aber du sabotierst etwas, was du eigentlich gut findest, um deine moralische überlegenheit auszuleben.

most importantly, because there is no need. the reward for mining via coinbase transaction is increasing with rising bitcoin value and will likely do so for considerable time. with a money supply inflation >1% for over a decade its not neccessary to maximize incentive through fees. its not productive to let a currency have 10% of the total money supply as yearly maintenance costs.
fees as extra incentive are a short-term non-issue. its much more important to optimize fees and block size for a well-running network and best user-experience.

i bought a raspberry rev b to excusively use with armory. i ran into the exact same problem using raspian described here:
https://bitcointalk.org/index.php?topic=156003.0

is there any confirmed method to get armory running on a raspberry? i am willing install any OS as long as armory works.