Re: [Bitcoin-development] Happy new year!
Same here. I feel incredibly lucky to know some of you, and to be able to contribute in some small way to what this is ultimately becoming. It's been an amazing ride, and I'm pretty sure that 2014 is going to totally blow our minds. -wendell hivewallet.com | twitter.com/hivewallet | pgp: B7179FA88C498718 On Jan 1, 2014, at 1:33 PM, Mike Hearn wrote: Bitcoin had an incredible year in 2013, and I very much enjoyed working with and meeting you all. I'm very much looking forward to some of the upgrades coming in 2014. Though a lot happened in the general community, last year was kind of quiet with respect to the core software. I'm hoping this year we can pick up the pace a little. Cheers! -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DarkWallet Best Practices
Amazingly thorough, Peter. Thanks so much! -wendell hivewallet.com | twitter.com/hivewallet | pgp: B7179FA88C498718 On Dec 19, 2013, at 8:17 AM, Peter Todd wrote: Here's my draft. I don't claim this to be official, but I think this should represent the consensus we've come to at the DarkWallet Hackathon; I'm writing it up as an email in part to preserve a record of that consensus. * General Principles We believe in decentralization, user-defined privacy, education as opposed to magic, and security based on openness rather than just trust. We consider users who are individuals as well as the needs of businesses such as merchants and exchanges. We recognize that often the more people who use privacy protection technologies such as CoinJoin, the better protected we all are. * Privacy Bitcoin inherently makes the flow of money visible, however it does not require that flow to have real-world identities attached, or even for that matter, pseudonyms. We see this as an unfortunate flaw in the Bitcoin protocol that is to be corrected; the Satoshi whitepaper itself included one such correction by outlining how avoiding address re-use helped preserve privacy. ** Threat model We assume a worst-case sophisticated state-level attacker with the goal of deanonymizing and otherwise subverting Bitcoin users. Such an attacker can be assumed to control up to 100% of the Bitcoin relay network as well as have the ability to wiretap up to 100% of the node-to-node traffic. (for nodes that they do not control) Such attackers are however constrained by politics and budget. We assume they use their ability to conduct MITM attacks sparingly - for instance by subverting certificate authorities - due to the risk of detection. (note how such attackers may be more willing to use detectable attacks in the future now that their activities are public knowledge) We also assume that while their budgets for individual targets may be very large, the equally large number of targets required for en-mass survailance leads to relatively low budgets per target. In particular note how the 51% assumption assumes that the overall economic value of Bitcoin to its participants is greater than the attacker's budget by some margin. ** Address re-use Wallet software SHALL avoid address re-use. New addresses will be used for all change and users will be encouraged through the user-interface and other measures to use new addresses for every payment to the wallet. ** CoinJoin With CoinJoin the more users that make use of it, the larger the anonymity set and the better protected user privacy is. Thus we encourage wallet software to agressively make trade-offs between absolute privacy and usability; compromise is not a dirty word. Wallet software SHALL implement basic two-party mix functionality and MAY implement more sophisticated CoinJoin functionality such as n-party mixes. CoinJoin SHALL be the default way that all transactions are sent. Wallet authors are cautioned that more sophisticated functionality may be more secure in theory, but if users do not use it the functionality is wasted; focus on the general case first and only then try to improve. *** Two-Party Mixes The most basic form of CoinJoin is for two parties to author a transaction. A key distinction between a 2 party mix and an n-party mix is that in the two party case both parties automatically learn the other's inputs and outputs by simple elimination; sophisticated cryptographic blinding protocols are useless. To an external attacker each transaction doubles the size of the anonymity set: the coins may have come from one party or the other and the attacker has no way of knowing which. (modulo value analysis, which will be discussed later) *** n-party Mixes and Blinding If two parties can jointly author a transaction, n parties can too. Without special effort this has the disadvantage of revealing the input to output mapping to all parties. Various cryptographic blinding schemes have been proposed to fix this problem, either with multi-party computational techniques, or by making use of multiple communication channels along with a robust anti-DoS scheme. In either case, for now we reject such schemes as complex and inconvenient and prioritize robust two-party mixing. However we do take the existance of such schemes into account; note how a n-party mix can act as a single party in a two-party mix scheme. *** Four-stage two-party mix protocol on the wiki *** Defeating value analysis Attackers can make good guesses at the mapping of inputs to outputs based on value. For instance with two inputs of 3 and 5, and fours outputs of 1.4, 1.6, 2.4 and 2.6 the attacker can easily map inputs to outputs based on what values match up, in this case 3 split into 1.6 and 1.4, and 5 split into 2.4 and 2.6 Value Matching Not all CoinJoin users need
Re: [Bitcoin-development] Extending the Payment Protocol with vCards
Hi Mike, It seems to me there is some confusion about this. Taylor's talking about a standard way to pass around data; the end user would never be exposed to something like a vCard. That vCard's existence itself would in fact be very temporary. -wendell grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411 On Nov 10, 2013, at 7:08 PM, Mike Hearn wrote: It's great to see people thinking about payment protocol extensions. I'm not totally convinced vCard support is the best idea relative to social network integration - I can't recall the last time I saw someone use a vCard. However, that should not hold you back from experimenting or prototyping. All an extension requires is some tag numbers and we're not in danger of running out of numbers any time soon. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Introducing Hive, a new wallet for Mac OS X
Hi everyone, We have pushed out our first test release of Hive, a new OS X wallet focused on usability and discovery: https://bitcointalk.org/index.php?topic=304060 Hive is powered by a new version of our BitcoinKit.framework, updated recently with bitcoinj support. Memory of a famous Reid Hoffman quote implores us to reveal that Hive is still missing _many_ basic features. This is not a release that you should give to anyone for serious use. We wanted to get the ball rolling with the community as early as possible, to gather feedback -- and hopefully a little assistance! Thanks to everyone at Bitcoin Europe 2013 for the feedback and moral support! -wendell PS- If you're interested in including an app for your Bitcoin-supporting service in Hive, please be in touch! grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 signature.asc Description: Message signed with OpenPGP using GPGMail -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/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))
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! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140
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] Simple contacts exchange (was: Social network integration (brainstorm))
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! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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))
OK, I was under the impression that this was mostly developed for merchants. I've seen some discussion here that seemed to suggest it requiring some non-trivial (for an end user) steps like getting a CA-signed certificate. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 7, 2013, at 11:44 PM, Mike Hearn wrote: This is the sort of thing the payment protocol is for. The recipient would vend a PaymentRequest containing identity details. The sender would submit a Payment containing his/hers. The wallet then understands what to do. -- 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! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Social network integration (brainstorm)
Mike Hearn had a rather cool idea about watermarking images with Bitcoin addresses in order to facilitate auto-magically linking social networking profiles: apparently even without API access, reasonably large user images are available publicly via the major services (Facebook, Twitter). Since this process would necessarily be somewhat manual and would of course be undone anytime the user changed his/her profile image, it is probably not a solution for everyone. But it seems that this could be a helpful way to at least _begin_ organizing Bitcoin around people and organizations in a way that is broadly familiar. I haven't been able to get this to work myself, but Blockchain.info seems to offer sending 'coin via Facebook: https://blockchain.info/wallet/send-via There is also the very cute Bitcoins With Friends: https://bitcoinswithfriends.com/ Most of the other apps that I have seen at one point or another have vanished. I recall reading that Facebook was not particularly friendly to them, hence the present interest in more subversive (?) ways of making those connections. Again, I am not 100% sure that this is the correct place for it, but I'm opening this thread to other such ideas in case anyone else wants to discuss it. Our motivation is making Bitcoin easier to use, and we suspect that even imperfect social network support will move us closer to that goal. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 Re-orienting Bitcoin around people and companies is something we wanted to do for a long time. How do you get an address linked to a personal profile? Someone was asking me about this last month and I suggested watermarking addresses into social network profile pictures. The advantage of that approach is every social network supports profile pictures and big ones like Facebook and Twitter allow querying of somebodies picture without needing any API or user authentication, eg: https://graph.facebook.com/i.am.the.real.mike/picture?type=large So obviously with such a thing you can send to any Facebook user who has configured their profile correctly. There's a library that implements watermarking that can survive social network recompression, but it is (doh) written in Java ;) -- 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! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] An app store and non-network transaction fees
Hey Mike! On Sep 5, 2013, at 10:26 AM, Mike Hearn wrote: It might be simpler to not think of it as an app store, but rather see it as a set of affiliate schemes. To get placed into the apps section you can say that the business must have an affiliate scheme in place (i.e. open to more than just you) and then you use the normal mechanisms of affiliate codes and so on. If you refer a lot of users to that business, you get the referral bonuses. Affiliate schemes are a common way for open source projects to monetize - e.g. Firefox development is largely paid for by search engine referrals. It's compatible with the ideals of openness because their income relies directly on their traffic, and there are several competing search engines the projects can play off against each other to get the best prices. Also, users expect search engine integration these days, so they'd be sending search traffic regardless. In the long term, I think this makes perfect sense. After all, that's really what the first option is at its heart. About search engines, that's also a great point. We've thought about doing this, but my concern was that the ecosystem on the whole is too young and fragmented for this to make much sense. Until for example speciality search engines for Bitcoin products and services manifest (I'm sure they are coming), I suspect the results might be a little vague and unsatisfying. I really see Hive's app platform as a stepping-stone to more mature things. Hopefully several companies like BitPay end up offering both great affiliate programs and search engines very soon. Until then, that's why something like sending transaction fees directly from the user's wallet is even on the table. The apps don't have to be offline. They can (and probably should) be online, so the businesses can retain control of their features and brand. Yes, I should clarify. We do want businesses to be able to have that control. However we also want to do a kind of submission/review process in order to ensure some user experience continuity and also to monitor for potential exploits. The plan is ultimately to have a public repository for applications, maintained by us. We will review the pull requests of third parties and the Hive app will always try to pull the latest (approved) updates. Does that make sense? It's centralized responsibility and potential risk if we cannot keep up with demand, but again -- we want to try the approach, at least while starting out. The main downside, of course, is it distorts technical judgement. You can get projects pushing certain businesses heavily not because it's technically the best thing for users, but because their income depends on it. That's absolutely true, but at the moment the only thing I can really say is that we'll cross that bridge when we get there. ;-) One alternative funding model you could explore is allowing users to bid on assurance contracts for feature development. This means you think up a bunch of improvements you could make, then allow users to pledge Kickstarter-style towards their development. The upside is it allows the community to direct development, and users feel directly involved and not exploited. The downside is, no recurring income you can use to support yourself whilst engaged in other endeavours. Funny you should mention it! I just mocked this idea up last week, though I assumed a cruder system of voting to an address that corresponds to a feature -- literally, voting with your wallet (for your wallet, ad infinitum). I watched your talk about assurance contracts and other hidden features, but am not entirely sure that I understood it enough to know how it would work in this context. Sorry for the persistent hand-holding requests, but some advice would be very welcome. 2) Although our BitcoinKit.framework supports both bitcoind and bitcoinj, we will be using bitcoinj with an integrated VM for the time being. The main draw is SPV, although to be honest we would prefer to support the network more via something like Peter Todd's partial UTXO sets idea (hint hint, anyone?). Bear in mind that regardless of how much you want to support the network, it's ultimately your users resources that will actually get spent. That's why I'm a bit skeptical of any schemes that rely on random end users donating lots of cpu time or bandwidth to the network. If they want to do it, partial UTXO sets and other interesting ideas are worthwhile, but I guess most users won't. I think Bitcoin will over time be more and more like Tor where relays are run on dedicated servers by people who have some modicum of knowledge and community involvement. If it is a real burden for the users, that's the best argument I've yet heard. However, my impression from Peter's post was that it would be fairly painless for them. I guess there's also the question of diminishing returns: Is the network value of a
Re: [Bitcoin-development] Version 0.9 goals
Mike, If bitcoinj will be ready and you will help us, we are willing to implement it right away in Hive as well. We will also keep BitcoinKit.framework updated with the new bitcoind and bitcoinj implementations. BitPay taking the lead here would be tremendous. Hopefully cool sites like Bitcoin Store will also be game to hit the ground running. I'll ask them. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 15, 2013, at 10:09 AM, Mike Hearn wrote: Pieter, Matt and I also agreed that for maximum impact we should really try to ship payment protocol support in at least two clients simultaneously and ideally with a big merchant signed up too - to send a powerful message that we really mean it. Someone volunteered last week to do it for bitcoinj and if he doesn't pull through, I have some old code from EOY 2012 that I could update to the latest spec and ship at least some basic support. I'd hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has support pretty fast. Also, Jeff said that BitPay want to be a leader in support for the protocol. So let's try and co-ordinate release dates so we can make a bit of a splash and grab the ecosystems attention. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] SPV client in pure JavaScript?
To those of you in the know about modern browser tech: Does it seem at all conceivable that an SPV wallet could be built entirely in JavaScript? And if indeed it is within the realm of the possible, how would such a thing be safely distributed for use? Would a signed Chrome Plugin be an ideal vehicle? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 signature.asc Description: Message signed with OpenPGP using GPGMail -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Idea for new payment protocol PKI
We have been discussing something like this over here too, as well as exploring more esoteric blockchain+signature-based SSO implementations as discussed by John Light and others. One of our long-term ambitions with Hive is to provide a (mostly) user-transparent, decentralized authentication service. It sounds like our infrastructure could already handle a Persona implementation, and we very much want to get behind some forward-thinking standard. So as long as the plan _IS_ to remove said 'centralized struts' at the appropriate time, I'd say we're interested in exploring this further. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote: This is just me making notes for myself, I'm not seriously suggesting this be implemented any time soon. Mozilla Persona is an infrastructure for web based single sign on. It works by having email providers sign temporary certificates for their users, whose browsers then sign server-provided challenges to prove their email address. Because an SSO system is a classic chicken/egg setup, they run various fallback services that allow anyone with an email address to take part. They also integrate with the Google/Yahoo SSO systems as well. The intention being that they do this until Persona becomes big enough to matter, and then they can remove the centralised struts and the system becomes transparently decentralised. In other words, they seem to do a lot of things right. Of course you can already sign payments using an X.509 cert issued to an email address with v1 of the payment protocol, so technically no new PKI is needed. But the benefit of leveraging Persona would be convenience - you can get yourself a Persona cert and use it to sign in to websites with a single click, and the user experience is smart and professional. CAs in contrast are designed for web site admins really so the experience of getting a cert for an email address is rather variable and more heavyweight. Unfortunately Persona does not use X.509. It uses a custom thing based on JSON. However, under the hood it's just assertions signed by RSA keys, so an implementation is likely to be quite easy. From the users perspective, their wallet app would embed a browser and drive it as if it were signing into a website, but stop after the user is signed into Persona and a user cert has been provisioned. It can then sign payment requests automatically. For many users, it'd be just one click, which is pretty neat. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV client in pure JavaScript?
Packaged app pages always load locally. This allows apps to be less dependent on the network. Once a user installs an app, they have full control over the app's lifecycle. Apps open and close quickly, and the system can shut apps down at any time to improve performance. Users can fully uninstall apps. Does this mean that upon install, a nice, icon-emblazoned package will drop into my /Applications folder on a Mac, or in my Windows Start menu, etc... Or are packaged apps always launched and maintained from within Chrome itself? Provided that the technical stuff could be made to work within the context of the more limited API, this certainly seems like an interesting, user-friendly way to distribute a Bitcoin wallet! -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 9, 2013, at 2:14 PM, Mike Hearn wrote: Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP socket connections: http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html You would do it as a packaged app: http://developer.chrome.com/apps/about_apps.html because then they're a lot more similar to native apps (they get their own windows, run offline, etc). But these aren't standard APIs. They're all Chrome extensions. I doubt HTML5 will support USB access anytime soon, for instance, but packaged apps do. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV client in pure JavaScript?
No, it's not -- but that's certainly very cool to see Jeff. How is BitPay going to put this to use? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 9, 2013, at 3:08 PM, Jeff Garzik wrote: Certainly. BitPay is working on such a wallet: https://github.com/jgarzik/wally wally uses node.js JavaScript, and not browser JavaScript, so not exactly what you're talking about... -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BitMail.sf.net - encrypted p2p email
Jesus, please stop this. :( -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 9, 2013, at 9:01 PM, Randolph D. wrote: anyone tested the secure encrypted p2p email: http://bitmail.sf.net SVN here: svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code http://sourceforge.net/p/spot-on/code/commit_browser -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Safe auto-updating
For usability purposes, we at Hive would like to have an auto-updater in our wallet app. What is a safe way to do this? I understand that Bitcoin-QT lacks such an updater for security reasons... Has been thought out in more detail since that decision was made? We have been toying around with the idea of placing one server behind a Tor hidden service, whose only function is to output a checksum of the update package. The theory is that if it is well-secured, it will at least be immune to tampering at the physical hosting level. Any thoughts or advice about any of this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 signature.asc Description: Message signed with OpenPGP using GPGMail -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BitMail - p2p Email 0.1. beta
Can you explain this process for those of us not too familiar with TPM chips? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: As a testament to the seriousness with which Pond takes forward security, it can use the NVRAM in a TPM chip to reliably destroy keys for data that an SSD device might have otherwise made un-erasable. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor and Bitcoin
Thank you Peter. Does this advice apply equally to both full and SPV nodes? At this point I'm merely curious, since we don't have the option to run bitcoinj over Tor right now anyway. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Jul 30, 2013, at 8:30 PM, Peter Todd wrote: tl;dr: Users should be using Tor to preserve their privacy and the MITM risks are minimal to anyone using Bitcoin correctly. (don't trust zero-conf transactions, they are not secure!) signature.asc Description: Message signed with OpenPGP using GPGMail -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)
Heh, will do. If you have less confidence in your programming skills perhaps its best if you write documentation and we bring in someone else to do the heavy lifting? Maybe Eric Lombrozo would be interested in this, for example... -wendell grabhive.com | twitter.com/grabhive On Jul 18, 2013, at 6:22 PM, Peter Todd wrote: I've got one or two orders of magnitude more good ideas than I have time to implement, but I will say this one would have a pretty big impact - I'm considering it. Of course, I would accept bribes. :) But in all seriousness I also accepted funds from John Dillon to implement replace-by-fee, although he's been good in understanding that the scope of the project was quite a bit bigger than originally thought. (it turned out replace-by-fee can enable very safe zero-conf transactions, but only with mempool and relaying changes) I'd suggest looking at my git commit track record before you offer anything FWIW; I've been much more of an academic than a programmer. signature.asc Description: Message signed with OpenPGP using GPGMail -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)
Peter, This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it. Will you implement this? -wendell grabhive.com | twitter.com/grabhive On Jul 17, 2013, at 12:58 PM, Peter Todd wrote: So what's useful about that? Basically it means your node starts with the same security level, and usefulness to the network, as a SPV node. But over time you keep downloading blocks as they are created, and with whatever bandwidth you have left (out of some user-configurable allocation) you download additional blocks going further and further back in time. Gradually your UTXO set becomes more complete, and over time you can verify a higher and higher % of all valid transactions. Eventually your node becomes a full node, but in the meantime it was still useful for the user, and still contributed to the network by relaying blocks and an increasingly large subset of all transactions. (optionally you can store a subset of the chain history too for other nodes to bootstrap from) You've also got better security because you *are* validating blocks, starting off incompletely, and increasingly completely until your finally validating fully. Privacy is improved, for both you and others, by mixing your transactions with others and adding to the overall anonymity set. In the future we'll have miners commit a hash of the UTXO set, and that gives us even more options to, for instance, have relayed transactions include proof that their inputs were valid, allowing all nodes to relay them safely. signature.asc Description: Message signed with OpenPGP using GPGMail -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Introducing BitcoinKit.framework
I for one would be interested in taking a look at that. In San Jose I was asking around about the possibility of hiring someone to complete such a patch. Pieter Wuille introduced me to Eric Lombrozo, who expressed interest, but has since gotten quite busy. So we haven't arrived at a detailed estimate of what it would involve. Maybe it would be better to start a completely new thread for this topic, but I would very much be interested in an open dissection of what adding SPV support to bitcoind would take. I am willing to fund or (ideally) co-fund this endeavor, if I can ever get my head around it. I'm super interested in all of these possibilities (including micro-stripped-VMs and transpilation), but would simply like to encourage the proliferation of _options_ whenever possible. -wendell grabhive.com | twitter.com/grabhive On Jul 16, 2013, at 11:51 AM, Mike Hearn wrote: If you wanted to implement SPV mode in bitcoind, Gavin or I could send you Satoshi's old patch although of course it is no longer usable. It would indicate the basic cut lines though. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)
Hello everyone, In the previous thread, I expressed interest in seeing an SPV bitcoind, further stating that I would fund such work. Mike Hearn followed up with some of Satoshi's old code for this, which is now quite broken. The offer and interest on my side still stand, as more diversity in SPV options seems like the right way to go. Time-permitting, I would really appreciate feedback from knowledgable parties about the possible approaches to an SPV bitcoind. We at Hive ideally want to see something that could one be merge into master, rather than a fork. -wendell grabhive.com | twitter.com/grabhive -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Introducing BitcoinKit.framework
Hi devs, Just wanted to cross-post this here since it seems very relevant. We're launching BitcoinKit.framework, a Cocoa framework that allows developers to write Bitcoin wallet apps for Mac OS X. BitcoinKit uses bitcoind, and serves a small and tidy API for developer use. Support for other Bitcoin implementations (libcbitcoin, etc) is soon to follow. BitcoinKit's first application is as the backbone of a new Mac wallet app called Hive, which will be released soon at www.grabhive.com. Grab the source here: https://github.com/grabhive/BitcoinKit Support is available via GitHub issues and this Bitcointalk thread: https://bitcointalk.org/index.php?topic=256583.msg2733523 A sample GUI app is also included: http://imgur.com/FzqA00X Cheers everyone! -Wendell signature.asc Description: Message signed with OpenPGP using GPGMail -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Introducing BitcoinKit.framework
Hi Mike, You are absolutely right about the synchronize time, it's one of our main frustration points right now and we clearly won't deliver the kind of user experience we want, without fixing this. Actually we were thinking of extending Jeff Garzik's picocoin as time permits, but the plan is far from concrete at the moment. What you say about trans-piling bitcoinj is _really_ appealing. We discounted Java simply because an OS X JVM is no longer guaranteed, but otherwise bitcoinj is ideal for our purposes. How can we assist or otherwise accelerate such an effort? -w On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote: That's great! I'm all for more wallets, especially user friendly UIs. However being based on bitcoind means it will take a very long time to synchronize for new users. We know a lot of users drop out. The best fix for this is SPV mode. Do you have any plans in this direction? So far, the only SPV mode implementation I know about is bitcoinj. I am experimenting with trans-piling bitcoinj to C++ to make it usable from Objective-C++ exactly with your use case in mind. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
