Stefan Thomas ... his emphasis on splitting secrets across two independent hosts with different security measures was inspiring. When I tried to talk to him about the basic idea he left a narrow minded impression to me as my interpretation of his response was something like "you can do it your way. my software does it this way." Kind of a downer but maybe it was a misunderstanding. I feel like I should explain where I was coming from there. I'm definitely sorry I came off so dismissive. My point was that I don't presume to know what the right solution is. After the talk, I talked to ten or more different people and every single person had their own different idea on how it should be done. So at some point I just threw up my hands, saying "I don't know what the correct way is." We will have to follow multiple avenues and let the market decide. What people end up using/recommending and what gets hacked the least, that's the best solution. |
|
|
|
What is the nature of Safeb.it's relationship with Wagner?
There's no special relationship. Bruce contacted me to ask if I was doing anything interesting and that was in the same week where Safebit hired me as a consultant, so I suggested that I come on with Eli to talk about their client. Bruce's reputation may be tarnished, but to be honest there really aren't that many Bitcoin tv shows to choose from.  |
|
|
|
BitcoinJS uses LevelDB by Google which is significantly faster than BDB, is cross-platform and under the New BSD License: http://code.google.com/p/leveldb/Can recommend. |
|
|
|
The Bitcoin days destroyed question has a pretty good answer explaining the concept and it was posted on hackernews. That's why it is so popular Yeah, also it got posted to Hacker News.  I see why it's popular and I have no issue with it, the OCD part of me just wants the other one to be on top.  |
|
|
|
Thanks. I hope some people vote for "How to concisely explain Bitcoin" though. Bitcoin days destroyed probably shouldn't exactly be the no 1 question. |
|
|
|
Added 8 BTC. Also made some improvements to the site today (new Q&A section, bugfixes). A new Getting Started section is in the works! |
|
|
|
Fellow Bitcoineers and Bitcoinettes, We just removed the old Privacy & Security section on WeUseCoins and replaced it with a Q'n'A section powered by the Bitcoin StackExchange. Check it out: http://www.weusecoins.com/questions.phpIf you have an account at Bitcoin StackExchange, please help by submitting and voting for interesting questions! Thanks! We're very lazy community-oriented, so we thought this would be much more interesting and more engaging than a static FAQ section. |
|
|
|
|
Interested, offering $155 in BTC equivalency.
(I'm not in the US, but I have a US address you can ship to.)
|
|
|
|
|
If they were stored sequentially, you'd need all transactions to verify that any single one belongs to a given block. With a merkle tree, you only need to provide the transaction and the merkle branch to prove that this transaction in fact appears in this block.
|
|
|
|
Ich finde es ein wenig schade, dass immer wieder auf Meze-Grill in NY verwiesen wird, wo es doch direkt in Berlin-Kreuzberg einen wunderbaren Burgerladen gibt, der hervorragendes Essen anbietet und Bitcoin als Zahlungsmittel akzeptiert. Gerade für deutsche Bitcoin-Neulinge sollte man dieses Beispiel häufiger anbringen, um die praktischen Anwendungsmöglichkeiten hervorzuheben. Man muss eben nicht erst nach New York fliegen, um die Währung der Zukunft irl zu nutzen. Guter Punkt. Ich hab da nicht groß nachgedacht, New York war halt wo ich persönlich es schon ausprobiert hatte. Wenn es in Stuttgart was gegeben hätte, hätten wir den Bezahlvorgang übrigens sogar gefilmt. Für solche Beiträge fällt das Gebührenzahlen nicht mehr allzu schwer. Man müsste sie jetzt nur noch in Bitcoin zahlen können. Danke an alle für euer Feedback! |
|
|
|
We've successfully incorporated Stefans script into StrongCoin. We're now creating Bitcoin key pairs, encrypting them and creating patyments all on the client side.
Are you running your own exit node? |
|
|
|
I guess there's no practical benefit to exporting a transaction rather than an address key pair. I don't like the idea of dividing coins among a plethora of tiny offline address balances.
I don't follow. The obvious benefit to exporting a transaction rather than the whole keypair is the ability to spend only part of the money, i.e. any amount. Why would you divide coins among a plethora of tiny offline address balances? |
|
|
|
Sure, but I see this like a traveler check 'signed' with a password, an honorable deposit like money on a poker table, or a reservation. But it can also be used to transfer funds from a sterile computer in a vault that was never tasted a network connection.
Hmm, well, keep in mind that at some point the computer where you want to sign the transaction needs some information from the block chain, namely the transaction hash, output index and value of each output that he wants to use. So if the sender truly wants to stay offline, somebody who is online (for example the recipient) would have to create the transaction (without signatures), hand it to the sender and the sender would then check it, sign it and hand it back. |
|
|
|
Stefan, how close are we to the user-case whereby I can take a memorized passphrase, hash it to generate a private key, generate a transaction offline, then email the transaction so that the recipient can broadcast the payment at his leisure?
I'd say about a 40BTC bounty away. All you'd need to do is create an HTML page (which you could of course save to your hard drive and run locally) that generates a key from the passphrase and prints out the signed transaction as base64. Then to make an HTML page that takes a base64 transaction and sends it to a the network would be simply: var txBase64= "...";
var exit = new Bitcoin.ExitNode("exit.trucoin.com", 3125, /* SSL= */ true);
exit.query('tx/send', {tx: txBase64}, true, function (res) {
if (res.success) {
// Successfully sent
}
});
The main problem I see is that until the recipient actually publishes the transaction the sender could double spend. So the recipient shouldn't actually deliver his goods or whatever until he has actually published the transaction and preferably until it has made its way into a block. |
|
|
|
Der ZDF-info Beitrag zu dem ich interviewt wurde ist jetzt online auf YouTube: http://www.youtube.com/watch?v=CdNh3Fcdpx8Viel Spaß beim Anschauen! Edit: Ich hoffe es nimmt mir keiner übel, das ich den Leuten von großen Bitcoin-Investments abgeraten habe - ich glaube einfach, dass es Bitcoin eher schadet wenn die Spekulation gegenüber der realen Nutzung einen zu großen Stellenwert einnimmt. |
|
|
|
Bounty received! |
|
|
|
I wrote a response to that article here. That response deals mostly with our implementations though. The basic argument of the article is that you need to trust the server to deliver valid code, which is true. But nobody disputes that. To get around the problem there are plenty of other ways you can deliver the code, like browser extensions, downloadable apps, etc. It's still nice if your app also runs without installation, even if you have to trust the server in that case. A longer refutation of the article by Nadim Kobeissi can be found here. |
|
|
|
Just sent a partial solution (no UI) via PM. |
|
|
|
|
Show Posts
