Re: [Bitcoin-development] Why are we bleeding nodes?
On that note, I think we have every possibility to make desktop and mobile wallets mind-numbingly simple -- and perhaps even do one better. Is this now a community priority? If so, I would really appreciate some additional contributors to Hive! https://github.com/hivewallet/hive-osx https://github.com/hivewallet/hive-android -wendell hivewallet.com | twitter.com/hivewallet | pgp 0x8C498718 twitter.com/bitcoinbookclub | campbitcoin.hivewallet.com On Apr 7, 2014, at 9:15 PM, Eric Martindale wrote: > We need to make it so mind-numbingly simple to "run Bitcoin correctly" that > the average user doesn't find reasons to do so in the course of normal use. > Right now, Coinbase and Bitstamp are winning in the user experience battle, > which technically endanger the user, and by proxy the Bitcoin network. > > Multi-sig as a default is a start. It won't succeed unless the user > experience is simply better than trusted third parties, but we need to start > the education process with the very basic fundamental: trusting a third-party > with full access to your Bitcoin is just replacing one centralized banking > system with another. signature.asc Description: Message signed with OpenPGP using GPGMail -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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=84349831&iu=/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 proto
Re: [Bitcoin-development] moving the default display to mbtc
We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: > Go straight to uBTC. Humans and existing computer systems handle numbers to > the left of the decimals just fine (HK Dollars, Yen). The opposite is > untrue (QuickBooks really does not like 3+ decimal places). -- 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=63469471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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=63469471&iu=/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
We've gone ahead and pushed a v1 API for this idea: https://bitcointalk.org/index.php?topic=313352 No fees yet, just the basics. -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 5, 2013, at 10:26 AM, Mike Hearn wrote: > Hey Wendell, > > Interesting idea you have there! -- 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=60135031&iu=/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=60133471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
Thanks Mike. I definitely took all your comments to heart, but we're looking to road-test something quickly for the sake of user experience in our own wallet. I wouldn't mind us contributing to a BIP once we have a better grip on the payment protocol itself, but (for example) I'm still not sure that I understand _why_ signed certificates are even required. Isn't that likely be an obstacle to adoption for use cases like this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Sep 17, 2013, at 12:03 PM, Mike Hearn wrote: > You can prove ownership of a private key by signing a challenger-generated > nonce with the public part and giving the signature back to the challenger - > same as with any asymmetric crypto system. > > As I already noted, the payment protocol is designed to solve that problem. > You could design a BIP that extended the payment protocol to include > information about the person who generated it. > >> On Tue, Sep 17, 2013 at 11:30 AM, Wendell 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=58041151&iu=/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 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,
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 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=58041391&iu=/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=58041151&iu=/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=58041391&iu=/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=58041391&iu=/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
On Sep 5, 2013, at 12:14 PM, Mike Hearn wrote: > On Thu, Sep 5, 2013 at 12:04 PM, Wendell wrote: >> 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. > > Well, it's a bit complicated and needs some software development to do well. > The best way to fund a complex project would be to raise the money using an > assurance contr oh wait ;) Well, let's assume that our "public good" is based on the 5-step model described here: https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts This good corresponds to something like "Facebook contact synchronization" and has a target of 50 BTC, though we also want to be able to take more if people are willing to give it. >From here, it is unfortunately a little over our collective heads; we have as >of yet no experience with the scripting language. I suppose I'm trying to >twist your arm for an example, and maybe an anecdote. How would we do it? Does >it require the donors to do anything esoteric? I saw "but they do not >broadcast it" -- does this happen automatically when coins are sent to that >address, for example? Confused but enthusiastic, -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=58041391&iu=/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
[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=58041391&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] An "app store" and non-network transaction fees
Hi everyone, Our OS X wallet "Hive" features an integrated application platform. We hope this will be a great way for folks new to Bitcoin to discover a variety of Bitcoin businesses, from exchanges, to merchants, to games. The applications are locally hosted HTML/JS, and generally feature the most stripped-down UIs possible. We display them in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes and everything feels nicely integrated and secure. Should Hive succeed in gaining a foothold, we hope that we may one day be able to sustain ourselves via an aggregate of very small fees on transactions within this app platform. We like the approach because it lets us stay focused on making Hive great, and keeping it free, but at the same time we recognize that it is a kind of obligatory middleman... With all that that implies? I'm not totally sure, and that's what the question is about. Obviously there are a couple of brain-dead approaches: We could track what users do in the app, and send the business a bill (with blockchain proof, of course). Or, we could avoid troubling the business and have each user send a micro-transaction to some address of our choosing. The first one is messy and essentially makes us spyware. The second one is technically difficult, making a mess of transaction history, balances, and possibly in-app price listings. I'm not happy with either, but would lean towards the second one if I had to choose. I'm not 100% sure if this is the appropriate venue for it, but before we make that decision, I wanted to state our intentions and see if I could get some fresher ideas in the door. We want to be as ethical and (ideally) decentralized as possible -- priorities #1 and #2 -- but are otherwise open-minded. Some technical details for the curious: 1) Yes, everything will be free software under a GPL license -- including the app store and the apps themselves! That may seem to be risky given our proposed business model, but we are open-minded and think we very much welcome the 'competition' of a would-be forker / hope we can work together. ;-) 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?). We will be at the conference in Amsterdam on the 27th of this month if any of you want to meet and discuss. Thanks for your time, -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=58041391&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bloom io attack effectiveness
John, I for one support your rallying cry of decentralization. If you are implying that even 10,000 full nodes seems far, far too few for a distributed system that may ultimately face a very well-connected and well-funded threat model, I agree with you completely. However, I took Gavin's statement to mean something like a factual statement about the load-bearing nature of that many nodes, rather than an actual target number for some future iteration of the network. Partial UTXO sets sound like a great idea -- are they really being ignored? I am pretty new to the development process here, but I assumed (as with many open source projects) that ideation, debate and implementation take a while to churn. Has a prototype of that been developed already, are you implying that you funded something like that and it never got built? If there are some GitHub links that I missed, please send them over. Maybe you should open that topic back up in its own thread, so we can bring it back into view? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 19, 2013, at 4:53 AM, John Dillon wrote: > So tell us how is your "vision" of 10,000 big beefy full nodes with SPV peers > any different from the Electrum model? These days Electrum clients have block > headers and verify that transactions have merkle paths to the block headers. > The only difference I see is that SPV uses bloom filtering and Electrum can > query by transaction. But Mike wants to add querying by transaction to full > nodes anyway, and one of the purported advantages of this UTXO proof stuff is > that you can query servers for UTXO's by address, so I see no difference at > all. A patch to do bloom filtering on Electrum would be amusing to me. > > Here you have Peter talking about clever ways to actually get decentralization > by having SPV peers donate back to the network with spare bandwidth, like > relaying blocks, not to mention his partial UTXO set ideas, and you completely > ignore that. But I guess that would raise ugly questions when people realize > they can't now contribute back to Bitcoin, because the blocksize is a gigabyte > of microtransactions... It may also raise ugly questions with regulators that > may find the idea of "full node == data chokepoint == regulatory chokepoint" > an > attractive notion. Why are there not any competent people other than Peter who > really have the guts to bring up these proposals? I've little luck getting > proof-of-concepts built for money anyway. Maybe we just have a darth of smart > competent people in this space. > > You do a good job of signaling your priorities Gavin. The payment protocol > includes no notion that you may want to pay anyone but a SSL certified > merchant. Yes I know the crypto can be upgraded, but it says volumes that you > pushed for that first, without even the slightest token effort to allow > individuals to participate in any way. Sad given you have made things *less* > secure because there is no safe way to get money *into* my wallet with the > payment protocol, but could have been. > > Tell me, when my decentralization pull-req is voted on, which way are you > planning on voting? signature.asc Description: Message signed with OpenPGP using GPGMail -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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=48897031&iu=/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=48897031&iu=/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=48897031&iu=/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=48897031&iu=/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?
Right, I'm not suggesting that we have this wallet in a web app, but rather precisely what you are talking about: using special browser features, and bundling it. I am fundamentally monoculture-opposed, but given Chrome's present installed base, that initial target makes sense to me, provided that we could have a one-click installation (as per normal, via the Chrome Store). Chrome also has this "Native Client" plug-in: I know next to nothing about it, and this goes off the rails of the Subject, but perhaps an SPV implementation there could be a solution to the concerns you expressed? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote: > JavaScript is turing complete so of course it can be done. The real question > you're asking is, can it be done in a web app? I think the answer is I think > "no" because web apps aren't allowed to make raw TCP socket connections. > > Now there may be a way around that by using browser-specific things like > extensions or "installable apps" which give your code greater access > permissions. This approach means you essentially use Chrome as your app > platform instead of a JVM, the assumption presumably being that more users > have Chrome than a JVM. The flip side is that users who don't would probably > balk at the idea of installing an entire browser in order to run a wallet > app, whereas a JVM can be bundled and the resulting app acts like any other. > I don't know of a convenient way to "statically link" Chrome into a > regular-looking application. > > I personally wouldn't find such a design compelling. Whilst Java isn't > exactly a great language, JavaScript is significantly worse in virtually all > aspects. I don't understand why anyone would want to use JavaScript outside > the browser - you get less safety, less performance, fewer features, less > mature tools and so on. If the end result is an installable app like any > other, all you did is cripple yourself vs the competition that's using > languages/platforms designed for it. -- 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=48897031&iu=/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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Safe auto-updating
That multisignature/blockchain commitment idea seems really solid, Peter. Thanks very much indeed everyone, this is all very helpful. Much to research and think about. Interestingly, a thread is presently raging on liberationtech about Tor Browser Bundle, and the subject of automatic updates has come up. Gregory Maxwell responded thusly (cross-posting for completeness): > _please_ don't deploy automatic updates in a sensitive environment > like this without at least quorum signatures (like gitian downloader) > and timed quarantine with negative signatures (harder to make strong > absent a jamming proof network). -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Aug 5, 2013, at 7:49 PM, Peter Todd wrote: > Gregory Maxwell had some good ideas along these lines at the san jose > conference. Extending gitian with these kinds of features would be a good > approach. > > But I think its worth thinking about attack models. A huge danger with > auto-updating is that it is easy to target individuals; if I leave > auto-updates on I am essentially trusting the developers capable of signing > an update not to specifically try to attack me in the future, a much more > risky thing to do than simply trusting them not to release a malicious > release. > > Sure you can try to implement anonymous downloads and similar mechanisms, but > they all tend to be fragile with regard to deanonymization attacks. > > A better way is to ensure that the act of making a release available for > download must be public, even if you can control what binaries are made > available to a particular target. You can do this by putting a commitment in > the blockchain itself. Each person on the signing list creates a transaction > with a special form from a specific pubkey that commits to the digest of the > binaries, and the auto-update code refuses to update unless it sees that > special transaction with a sufficient number of confirmations. The developers > now can't make a special release for a specific target without letting the > world know they did so, even under coercion. > > They developers could of course still make a release with code inside > targeting a specific individual, but in theory at least the public can check > if their builds are reproducible, and start asking questions why not? 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=48897031&iu=/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=49501711&iu=/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=49501711&iu=/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
I suppose it isn't quite what you're talking about but we did push this out today: Tor.framework, for Cocoa developers, similar to our BitcoinKit: https://github.com/grabhive/Tor.framework -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 On Jul 30, 2013, at 4:01 PM, Jeff Garzik wrote: > This has been discussed on IRC, and would be interesting to explore. > For several applications, linking directly with a Tor library is far > superior to the fragility of requiring a properly configured external > process. Lacking such a Tor library right now, one must be written > -- 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=49501711&iu=/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=49501711&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Endianness (was: Linux packaging letter)
Forking for curiosity's sake: Is there a substantial barrier to endian independence in the Bitcoin codebase? -wendell grabhive.com | twitter.com/grabhive On Jul 24, 2013, at 3:45 AM, Douglas Huff wrote: > The fact that you're even trying to package and/or at some point have > packaged and shipped big endian binaries is straight up *NEGLIGENT.* -- 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=48808831&iu=/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=48808831&iu=/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)
"The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!" Good lord Michael, I wish we had known about libcoin a month ago! -wendell grabhive.com | twitter.com/grabhive On Jul 17, 2013, at 4:31 PM, Michael Gronager wrote: > Hi Wendell, > > What Peter describes (a hash of the current set of UTXOs as part of the > coinbase) is already implemented in libcoin, on which you can easily build > both a bitcoind and any client. Libcoin is a library originally based on the > satoshi client, and as such it is compatible/replacable with "master". > > Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp > and the MerkleTrie classes then you can see how it works. > > What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, > there is some stub code for a p2pool like mining scheme ensuring several UTXO > hashes every 10 minutes, but I will not have time to finalize it the first > few months - anyone are of course welcome to help out ;) > > Michael 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
