Re: [Bitcoin-development] Happy new year!

2014-01-01 Thread Wendell
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

2013-12-19 Thread Wendell
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

2013-11-12 Thread Wendell
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

2013-09-28 Thread Wendell
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))

2013-09-17 Thread Wendell
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))

2013-09-17 Thread Wendell
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))

2013-09-16 Thread Wendell
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))

2013-09-09 Thread Wendell
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))

2013-09-06 Thread Wendell
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)

2013-09-05 Thread Wendell
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

2013-09-05 Thread Wendell
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

2013-08-15 Thread Wendell
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?

2013-08-09 Thread Wendell
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

2013-08-09 Thread Wendell
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?

2013-08-09 Thread Wendell
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?

2013-08-09 Thread Wendell
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

2013-08-09 Thread Wendell
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

2013-08-05 Thread Wendell
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

2013-07-30 Thread Wendell
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

2013-07-30 Thread Wendell
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)

2013-07-18 Thread Wendell
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)

2013-07-17 Thread Wendell
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

2013-07-16 Thread Wendell
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)

2013-07-16 Thread Wendell
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

2013-07-15 Thread Wendell
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

2013-07-15 Thread Wendell
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