I may be able to insure 1000 BTC, but I wouldn't want to have 1000 of my own BTC escrowed for this purpose, because then I can't invest these same 1000 BTC myself. This will make this ineffective IMO.
Fractional reserve insuring? What if a black swan turns up (after all, the inidividual investments being insured might be interdependent). We'd probably need re-insurers, but in the end, there can be no "insurer of last resort" with bitcoin. Is this a problem: the possibility of individual insurers to got bust, respectively all of them going bust in a chain-reaction in the case there's sufficient re-insuring? |
|
|
|
will the packages be signed? by who?
it depends on how the extension is distributed. note that we currently have the same problem with windows builds. yes,... and android, I guess, right? It's still unclear (as talked about on irc quite a while back) to me as to how package trust can be established. Surely you can't oversee / facilitate production of the packages for all the platforms and you're currently not the producer of the windows binaries, right? There also are no android packages as of now, correct? sorry to have veered a little off-topic, bit this issue is nagging in the back of my head. No problem, it is indeed an important issue. Note that the problem is a bit different for source code and compiled versions. For the bitcoin-qt client, binaries are compiled independently by several developers, and they check that they get the same result (they publish a hash of the compiled file). It would be nice to have that kind of check for the Windows binaries of Electrum. That's not a bad idea. You need at least 2 packagers per platform for that to work and some mechanism by which a rogue packager can be prevented to distribute his "alternative version". I doubt you'll get the users to compare hashes from different sources, so there has to be some instance or collaborative effort to do that? In addition, it would be good if the hashes would be published on a different website than the sitethat distributes the packages or binaries. (in case the site gets hacked)
maybe put them in the blockchain somehow? |
|
|
|
kam wohl nix wa  noch nicht... naja, die Welt wird auch daran nicht zugrunde gehen. |
|
|
|
When the pendulum swings it always overshoots the equilibrium so I'm certain we'll get at very least a small bubble I just don't want it to get prolonged and blown up into an unsustainable mania like last year.
But of course the market will do what the market will do..
i actually agree with this. it'll be interesting if this dynamic will come into play this time around though since we've already had our bubble. it really looks a lot like the NASDAQ bubble top from 2000 with a decline and slow rise to now. there are still plenty of skeptics around. the economy has matured significantly since last year and like you i hope it grows more organically. Bitcoin can FAIL at any moment OR it can become THE NEW MONEY. The community is plentiful and diverse, the time couldn't be more right, I'm confident. |
|
|
|
Man, please let this not be a huge bubble again..  it won't be. this will be healthy growth. *subdued* maybe a little tiny kids-bubble. We promise to not let it get that huge again, ok pap?? |
|
|
|
'cause you cleaned up your workplace?
Quick! Everyone clean their workplace! just did, very thoroughly, still no Magazine ;/ |
|
|
|
I do have bitcoin... about 1.3 bitcoins... all of it donated, won, or from the faucets. The thing that has kept me back from buying is largely the security aspect, also MtGox was really expensive but isn't as much anymore. I still don't trust it very much because of the security issues it has had. What do people say about Intersango or any other exchanges?
Better get them while they are still around $5.
i've always used just mtgox. wire them money, buy Bitcoins, and immediately transfer them to offline wallet. pretty safe. glad to hear the fees are better now. yes, better get them. I use intersango regularly and am content all-in-all, but the volume there is probably not enough for your purposes. If you think liquidity is an issue, you could try to find some big fish to sell to you without moving the markets. Any way you do it, I'd recommend going slow and also distributing amongst different exchange mechanisms. Don't just upload 250K USD to mtgox and hope everything will be fine. Do it in batches and grab the coins to your secure location whenever there are some. For secure storage a couple of possibilities in order of personal preference (ascending): * buy a couple of casascius 1 BTC coins and store your coins on them ((+), (-) you trust casascius, requires safekeeping (against theft and loss) of single coin) * use one of the brainwallet suggestions ((+) it's only in your brain, (-) but to sign you need to import into some client which is attackable) * use vanity-gen to generate random address, print the private key and put in safe location for later import into a wallet ((+) simple, low dependency impact, (-): requires safekeeping (against theft) of a non-encrypted private key) * improvement for vanity-gen-approach: encrypt the keys before you copy/store them. * use separate pc with armory, encrypted wallet (use long pw), make paper-backup of wallet seed, never connnect machine to internet, create watch-only-copy of the wallet and import that into another, this time well-connected instance of armory (allows to generate new addresses without also generating the private key). To transfer money, you'll need to generate a signing request, transfer that to the offline machine, sign it there, transfer the signed transaction back to well-connected armory for publishing. just my 20 mikes... |
|
|
|
Clemens Kap is probably involved. Those of you who have been to the Prague conference know him. He had this hw-device... wonder what's become of it. |
|
|
|
will the packages be signed? by who?
it depends on how the extension is distributed. note that we currently have the same problem with windows builds. yes,... and android, I guess, right? It's still unclear (as talked about on irc quite a while back) to me as to how package trust can be established. Surely you can't oversee / facilitate production of the packages for all the platforms and you're currently not the producer of the windows binaries, right? There also are no android packages as of now, correct? sorry to have veered a little off-topic, bit this issue is nagging in the back of my head. |
|
|
|
Das war auf meinen Mist gewachsen und leider scheint sich's die privacyfoundation anders überlegt zu haben: keine bitcoin-adresse mehr an o.g. URL  Habe mal, meinen damaligen email-verkehr referenzierend, nachgefragt... bin gespannt. Letztes mal war der Kontakt recht nett. |
|
|
|
No, I'm not sure it works on all systems. But I never had a complaint when using march=native, which should be the least-compitible compilation option.
Unless your compiler machine is in fact a i386, then "native" would be ok  It seems this issue is pretty much sorted-out, I guess the gcc sane default will be, well "sane". Thanks! |
|
|
|
|
will the packages be signed? by who?
|
|
|
|
Hi.
I'm Rob Sama, the guy behind BitPak and Ominous Megacorp. The 'Ominous' name is a bit of a joke, as the company is basically just me and some developers. I hope the name isn't too much of a put off.
We just submitted to the app store yesterday. So it will take some time before they approve or I fight with apple over it. I felt it was important to have a native iPhone client, so I went ahead and designed the app and recruited some developers to build it. As built, the app certainly isn't perfect. It takes forever to download the blocks, though it's speedy once they're downloaded. We're workiing on using an online database instead of downloading blocks for version 2.
Hey Rob, will the new version actually function? The last one I bought said: "downloading blockchain 0%" for weeks. |
|
|
|
just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.
I'm about to test... with "-march=i686", but other problems pop up.
didn't work (illegal instruction) I then tried with -march=i586 and after solving some other issues, like "forcing" to link against python2.6 (target system has python 2.6, build system 2.7). It now works, no more "illegal instruction" when creating a wallet. What didn't work well? The new binary installer that I posted? Or compiling for i586/i686? compiling for i686 didn't work, still "illegal instruction" on target system. compiling for i586 did the trick. I think the new .deb file I posted should work on other 32-bit linux systems, and if it doesn't, I really don't understand what's going on.
I might test it, but since I have a working version now, I'll probably do that after "import v0.6 satoshi wallet.dat" is implemented (unfortunately all wallets I want to import have been touched by newest git satoshi client). |
|
|
|
Ripple is a system where friends can lend each other money, via a chain/web of trust (A lends to B lends to C, because A trusts B trusts C). I was thinking of a problem I have - I would like to invest in an interest-baring investment, but all the Bitcoin investments I've seen so far seem risky to me. Pirate bonds, Pass-through pirate bonds, mining contracts ... since I'm not knowledgable about the people issuing these loans, or the mining profitability charts, I can't effectively calculate the risk of investing in them. Enters Ripple (or a Ripple-like system) What if I could use the market knowledge of people I trust, and invest through them? They will choose investments they trust, invest my money, and earn a commission for their services. There can be an arbitrarily long "investment path" - I trust A, A trusts B, B trusts C... This is a way to safely turn scary investments into safe ones, using only local knowledge and reputation. As long as each link of the chain trusts the next link, the entire chain is safe. If some link in the chain defaults, then it is the obligation of the previous link to absorb this default, because his own reputation is on the line ("My sub-investment defaulted" is not a valid excuse - I invested with you, not your next link). Someone can of course disperse the risk and split the investment between multiple channels, the chain doesn't have to be linear. I believe this is different than the core Ripple, which AFAIk is not designed for interest bearing investments but rather for zero-interest loans. Thoughts? ripper: "p2p insurance", I like the idea, still a bit cloudy, though... regarding above emphasis: shouldn't that be: "As long as each link of the chain trusts the next link, the entire chain is safe trusted."? What exactly happens in a case of default? Do the re-lenders in the chain provide the insurance and suffer loss of fund or do they pass the default on and "only" suffer loss of trust? I'm not so sure what exactly should be stored with the link. You said merely a scalar trust value is not enough, it should include affirmations of trust in the context of an interest rate and amount. Maybe something more even, maturity? What are the dimensions here? And: is this info supposed to be based on past experience or subjective impression? I think maybe the re-lenders should in fact provide insurance and maybe even proof of ownership of necessary funds to cover? Do you want to include "contracting" somehow within the system? Then maybe we could automatically mix, shuffle and re-package the debt and sell it as "highly secure AAA+ non-inflatable bitcoin debt" . Hmm, actually, scratch "automatically", this'd probably be exactly a job for someone within the chain, a debt-repackaging insurer or something. Well, now I'm just rambling on... better cut here. |
|
|
|
For "balance", in this context you can say "Umsätze", thats the common term.
For "freeze" you could say "lock" = "sperren".
"Unlock" = "freischalten" (1) or "entsperren" (2).
"Quellschlüssel" (source key) could be used for "seed".
"balance" is more like "Saldo" than Umsätze, right? "Quellenschlüssel"... hmm, hmmm. "seed" ist auf jeden fall ne harte Nuss. Könnte man wohl auch unübersetzt lassen. Wie wärs mit "Grundschlüssel" oder "Basisschlüssel", vielleicht auch ganz salopp: "Basiszahl"? |
|
|
|
just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.
I'm about to test... with "-march=i686", but other problems pop up.
didn't work (illegal instruction) I then tried with -march=i586 and after solving some other issues, like "forcing" to link against python2.6 (target system has python 2.6, build system 2.7). It now works, no more "illegal instruction" when creating a wallet. |
|
|
|
I'm experiencing the "Illegal instruction" problem on my first-gen asus eeepc.
It seems to be an invalid instruction in the binary (I used the dependency bundle).
Ran an strace and it seems to be in the random number generator somewhere (I can't see an actual stacktrace, how do I dump one).
So I guess one of the dependency libs might've been compiled for a different CPU.
Ideas anyone?
Actually, I just ran into this the other day, too. I don't know why it used to work and now it doesn't. I have been compiling the binaries on Ubuntu VMs and it seems that the 32-bit systems are creating bad binaries. Perhaps the CPU type of a 32-bit VM is "different"? Anyone have any problems with the 64-bit packages? I'll investigate this a little more thoroughly. For now, I'll just compile it on a physical 10.04 32-bit system I have. At least, the python2.6 package can be done there... what parts are you compiling? cpp4Swig? just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code. I'm about to test... with "-march=i686", but other problems pop up. |
|
|
|
|
Show Posts
