Wendell [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-07-15 to 2014-04-09
💬 Posted a total of 37 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvp

Profile Code

nprofile1qqsv2d9m2dw2r6ayvz4edtvxnnazzcp9ndzpe923tu5pcxrlqyc0fucwhx2xd

Author Public Key

npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvp

Show more details

Last Notes

2023-06-07 15:11:23

- reply

📅 Original date posted:2014-01-01
📝 Original message: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!

2023-06-07 15:09:42

- reply

📅 Original date posted:2013-11-18
📝 Original message: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).

2023-06-07 15:06:39

- reply

📅 Original date posted:2013-09-09
📝 Original message: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.

2023-06-07 15:06:38

- reply

📅 Original date posted:2013-09-17
📝 Original message: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 at 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

2023-06-07 15:06:37

- reply

📅 Original date posted:2013-09-16
📝 Original message: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 at 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=58041391&iu=/4140/ostg.clktrk_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:06:37

- reply

📅 Original date posted:2013-09-17
📝 Original message: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 at 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=58041391&iu=/4140/ostg.clktrk_______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:06:36

- reply

📅 Original date posted:2013-09-06
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130906/6be1e4b2/attachment.sig>

2023-06-07 15:06:35

- reply

📅 Original date posted:2013-09-05
📝 Original message: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 ;)

2023-06-07 15:06:32

- reply

📅 Original date posted:2013-09-05
📝 Original message: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 full "user" Bitcoin node less than one run on a dedicated server? Will it eventually be? I don't know enough about that to comment, but I do know that in the Tor example, exits are chosen based on some criteria (I think, available bandwidth?). Is there a parallel in Bitcoin?
(Probably best as a separate thread...)
Thanks for your thoughts, Mike.
-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130905/ffd6a3a5/attachment.sig>

2023-06-07 15:06:17

- reply

📅 Original date posted:2013-08-19
📝 Original message: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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130819/36d261e4/attachment.sig>

2023-06-07 15:05:57

- reply

📅 Original date posted:2013-08-15
📝 Original message: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.

2023-06-07 15:05:43

- reply

📅 Original date posted:2013-08-09
📝 Original message: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...

2023-06-07 15:05:43

- reply

📅 Original date posted:2013-08-09
📝 Original message:"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.

2023-06-07 15:05:42

- reply

📅 Original date posted:2013-08-09
📝 Original message: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.

2023-06-07 15:05:41

- reply

📅 Original date posted:2013-08-09
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130809/14986f4d/attachment.sig>

2023-06-07 15:05:32

- reply

📅 Original date posted:2013-08-05
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130805/bc30fd43/attachment.sig>

2023-06-07 15:05:19

- reply

📅 Original date posted:2013-07-30
📝 Original message: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.

2023-06-07 15:04:45

- reply

📅 Original date posted:2013-07-17
📝 Original message:"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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/eb021d7c/attachment.sig>

2023-06-07 15:04:44

- reply

📅 Original date posted:2013-07-17
📝 Original message: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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/e78aceae/attachment.sig>

2023-06-07 15:04:41

- reply

📅 Original date posted:2013-07-16
📝 Original message: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

2023-06-07 15:04:39

- reply

📅 Original date posted:2013-07-16
📝 Original message: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.

2023-06-07 15:04:36

- reply

📅 Original date posted:2013-07-15
📝 Original message: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.

2023-06-07 15:04:35

- reply

📅 Original date posted:2013-07-15
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130715/f4ae94ff/attachment.sig>