Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
Couple of things I just thought about: 1- Presume server should only sweep with two (or more, see below) revocation certificates being present 2- Need to insert something in the flow so that Alice can verify that the uploaded key is actually Bob's (and perhaps vise-versa, given an extremely dedicated attacker with a fast connection?). Is there a way to do #2 without creating yet another transaction? Admittedly I am still really puzzled about the accessibility of public keys in Bitcoin! Please remember that the idea is to have two wallets securely exchange a packet of metadata about a transaction beyond the scope of Bitcoin itself (a name, perhaps a small photo, etc) in order to increase usability. This will be my last post here on the topic except to reply in case anyone else contributes. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 16, 2013, at 4:05 PM, Wendell wrote: Luke pointed out that we should not be inserting extraneous data into the blockchain, so this sounds like the best option, Eric. I'm under the impression that a Bitcoin user Alice cannot see the actual public key of Bitcoin user Bob, so if we had Hive store metadata on a server relating to a given transaction ID, I would not be able to use those public keys key to encrypt. Is this a misunderstanding or is it correct? Assuming it is correct, the best that I could come up with was storing the transaction ID with a _fresh_ public key on a server, each time a transfer is made. Altogether it looks like this: - Alice generates a new keypair revocation certificate for the transaction - Alice makes a Bitcoin transaction to Bob - Alice sends the transaction ID plus the new public key to server - Bob receives the Bitcoin transaction - Bob generates a new keypair revocation certificate - Bob does a transaction ID lookup on the server, receives Alice's public key, sends his own new one - Bob encrypts his user metadata against Alice's new key - Alice downloads and decrypts Bob's metadata - Alice uploads her revocation certificate - Alice uploads her own metadata - Bob downloads Alice's metadata - Bob uploads his revocation certificate - (Server removes all keys with revocation certificates) I presume going the extra mile to generate new keys for each transaction is helpful for privacy? The above seems rather inelegant to me. I really don't like that clients (wallets) are going to be beating down the server all the time checking for keys, or that there is a possibility of a desynchronization so severe that the user receives the data much too late for it to be useful. But, I suppose it can work. Another thing I'm considering is Alice/Bob validating each other. I suppose we should include some kind of code that we encourage people to read to each other over the phone or some other medium, to ensure that it really is Alice, before (for example) returning money to a very legit-looking personage. Any other thoughts? I would love to do this without using any servers at all (serverless keyserver, anyone?), but I am not quite sure how. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 7, 2013, at 12:47 AM, Eric Lombrozo wrote: Why not just use the transaction hash itself for the lookup? Also, presumably you'd want to encrypt the data so that only the recipient of the transaction can do this lookup. -Eric On Sep 6, 2013, at 8:07 AM, Wendell w...@grabhive.com wrote: Hi all, We're thinking about ways of automatically exchanging contact details between wallets, in order to encourage the proliferation of identifiable names and photos rather than long and hard-to-verify addresses. The simplest version goes like this: 2 BTC Bitcoin is sent to someone, and a data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA, it's You received 2 BTC from Frank Jones including a nice photo. Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it. Any thoughts about this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
[Bitcoin-development] BIP32 (HD Wallets) implementation in Ruby
I've been hard at work completing an open source Ruby gem library (called MoneyTree) that implements Hierarchical Deterministic Bitcoin wallets (BIP32), and it's about ready for release. It passes all of the test vectors and has 100% code coverage. I've also written an extensive README which goes into depth about HD Wallets, which I'll probably be turning into a blog post. However, I'm pretty new to crypto, so I wanted to run it by this group first before releasing it. If anybody has knowledge of BIP32 and can give at a review, I would greatly appreciate it, and would be glad to add you as a contributor. If you have knowledge of the BIP32 spec, but not Ruby, you can still help by reading over my README for conceptual accuracy. Check out the repo here: https://github.com/wink/money-tree Thanks in advance, Micah Winkelspecht -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Faster databases than LevelDB
LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. HyperLevelDB is a forked LevelDB with some changes, mostly, finer grained locking and changes to how compaction works: http://hyperdex.org/performance/leveldb/ However, it comes with a caveat - one of the changes they made is to take away write throttling if compaction falls behind, the app itself is expected to do that. Sophia is a competitor to LevelDB. The website claims that in benchmarks it completely smokes LevelDB. I have not explored how it does this or tried to replicate their benchmarks myself: http://sphia.org/index.html http://sphia.org/benchmarks.html It's written in C and BSD licensed. As an example of the kind of speedup they claim to be capable of, they say LevelDB could do 167,476 random reads per second on their SSD based machine. Sophia could do 438,084 reads/sec. Random reads are of course the most interesting for us because that's what UTXO lookups involve. They also compare against HyperLevelDB, where the differences are much less pronounced and actually HyperLevelDB appears to be able to do random writes faster than Sophia. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
Nobody has written code to use a better format, migrate old wallets, etc. On Tue, Sep 17, 2013 at 1:41 PM, Jorge Timón jti...@monetize.io wrote: Only slightly related to this... What's the reason why BerkleyDB is maintained for the wallet? I think it would be a good thing to get rid of the libdb4.8++-dev dependency that makes bitcoind harder to compile on debian and ubuntu. Unless, of course, there's a reason I am missing... On 9/17/13, Mike Hearn m...@plan99.net wrote: LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. HyperLevelDB is a forked LevelDB with some changes, mostly, finer grained locking and changes to how compaction works: http://hyperdex.org/performance/leveldb/ However, it comes with a caveat - one of the changes they made is to take away write throttling if compaction falls behind, the app itself is expected to do that. Sophia is a competitor to LevelDB. The website claims that in benchmarks it completely smokes LevelDB. I have not explored how it does this or tried to replicate their benchmarks myself: http://sphia.org/index.html http://sphia.org/benchmarks.html It's written in C and BSD licensed. As an example of the kind of speedup they claim to be capable of, they say LevelDB could do 167,476 random reads per second on their SSD based machine. Sophia could do 438,084 reads/sec. Random reads are of course the most interesting for us because that's what UTXO lookups involve. They also compare against HyperLevelDB, where the differences are much less pronounced and actually HyperLevelDB appears to be able to do random writes faster than Sophia. -- Jorge Timón http://freico.in/ -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
The payment protocol doesn't *require* signed certificates, it just gives the option of using them. However if you don't have some kind of cryptographic proof of identity, what stops me putting your name and face into my payment requests and claiming to be you? -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
Thanks Mike. I definitely took all your comments to heart, but we're looking to road-test something quickly for the sake of user experience in our own wallet. I wouldn't mind us contributing to a BIP once we have a better grip on the payment protocol itself, but (for example) I'm still not sure that I understand _why_ signed certificates are even required. Isn't that likely be an obstacle to adoption for use cases like this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 17, 2013, at 12:03 PM, Mike Hearn wrote: You can prove ownership of a private key by signing a challenger-generated nonce with the public part and giving the signature back to the challenger - same as with any asymmetric crypto system. As I already noted, the payment protocol is designed to solve that problem. You could design a BIP that extended the payment protocol to include information about the person who generated it. On Tue, Sep 17, 2013 at 11:30 AM, Wendell w...@grabhive.com wrote: Couple of things I just thought about: 1- Presume server should only sweep with two (or more, see below) revocation certificates being present 2- Need to insert something in the flow so that Alice can verify that the uploaded key is actually Bob's (and perhaps vise-versa, given an extremely dedicated attacker with a fast connection?). Is there a way to do #2 without creating yet another transaction? Admittedly I am still really puzzled about the accessibility of public keys in Bitcoin! Please remember that the idea is to have two wallets securely exchange a packet of metadata about a transaction beyond the scope of Bitcoin itself (a name, perhaps a small photo, etc) in order to increase usability. This will be my last post here on the topic except to reply in case anyone else contributes. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
On Tue, Sep 17, 2013 at 4:00 AM, Mike Hearn m...@plan99.net wrote: LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. I'd looked at the hyperleveldb, but their performance graphs made it seem like it would be slower for the actual database sizes we're using today. Is there a competitor that specializes in being more robust to corruption? :( -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
On 9/17/13, Mike Hearn m...@plan99.net wrote: Nobody has written code to use a better format, migrate old wallets, etc. ACK, thanks. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Also somewhat related, I have been looking for some time now to abstract out the UTXO and block databases so that a variety of key/value stores could be used as a backend, configured by a command line parameter. In particular, it would be interesting for some server applications to support HyperDex, which is basically a distributed, fault-tolerant version of LevelDB: http://hyperdex.org/ By the same mechanism you could just as easily support a Sophia backend. Mark On 9/17/13 4:00 AM, Mike Hearn wrote: LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. HyperLevelDB is a forked LevelDB with some changes, mostly, finer grained locking and changes to how compaction works: http://hyperdex.org/performance/leveldb/ However, it comes with a caveat - one of the changes they made is to take away write throttling if compaction falls behind, the app itself is expected to do that. Sophia is a competitor to LevelDB. The website claims that in benchmarks it completely smokes LevelDB. I have not explored how it does this or tried to replicate their benchmarks myself: http://sphia.org/index.html http://sphia.org/benchmarks.html It's written in C and BSD licensed. As an example of the kind of speedup they claim to be capable of, they say LevelDB could do 167,476 random reads per second on their SSD based machine. Sophia could do 438,084 reads/sec. Random reads are of course the most interesting for us because that's what UTXO lookups involve. They also compare against HyperLevelDB, where the differences are much less pronounced and actually HyperLevelDB appears to be able to do random writes faster than Sophia. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOIymAAoJEAdzVfsmodw4H48QALC+ae4wRLEg3lrg9sgayfOn ukLM079PXgEbARFPt6WxkLnNGYzEbb7IzT0uvaKH4VIW/rrORy9VqNPmliF+834h XygUwfAzU04K/oLyCsdWZcOugj2P8aufNeA6whLS5IijDLtHb3Ueu4ORNcfLBGqp KKfqPj0QHseusiLJ9f3IW+LrdM1vAoT1jryTngpQy2i+qFFDM6CN3THCq4adJvjr AnYlfLoJSZ0/obz/krwLv6vP1BbwxXzv5CfD0Q2bdoEV/EgWDP3Bd5tUzUCjj53/ qMmhaACoVlarohh64s3JNSDSkHDFSbHFt65ZgNQbNY1wmSeyilQcd8FGWOF/WRzW Z/pl2IdhoCm3t86xSggRGivj/EVeBJlD36i7ohpDbVWFPsf6B4e5M6xSdso/2WBp fr55TwehCaGE+UHa0gITkE/si1txvY4gti0bLNvwFDEcZ3qsXRsz4CyLlZLMBbPX 4aRNGyqv2yJ2AivkEyNOUugo1Q8RKEKZWfWWDecI53DHdebzKX1zu9GLJwlGJqGw Qzm7Tdb7S8J/D6IIHf4Xq2LDhQ2fnPylmGSmtuVFEMxeDhmdbNqKSr3kqlWQf3T8 Oa8bm6kUQFJ+11jLEkVEGZJC4e42+faQBxR+CsqvVsTEezDCP1dE7D3QV8ry9YBc DwXt3299Q03B5LoxpWTq =KseH -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] the XBT
Hello, Has everyone seen http://www.coindesk.com/bitcoin-gaining-market-based-legitimacy-xbt/ Bitcoin has its own ISO currency code. Ron -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
