Topic: BitcoinSpinner - page 9. (Read 55544 times)

They are called volunteers 

Seriously, this could be part of the release process. New versions are released to the beta channel, once a trusted third party has downloaded and verified the build it is released to the general public.

your issue is the same with any wallet software of course. bitcoin-qt multibit, bitcoiJ based wallet for android, and even more blockchain.info.

it would make sense to have an independent service out there that downloads the apk from play store and verifies they correnspond to the source. unfortunately i don't know any such service.

what we can look into is signing of apks from multiple people. i will look into how android handles those.

The problem is that yes, I can do that but even though I call myself an Android Developer (see my sig first item and the pull request for Spinner) I run your binary of Mycelium now just because I'm lazy. You could literally go and take the $400 I currently store there. The only precaution I take is that I don't put my apps on auto-update so I update stuff only for a reason but with some time stamp triggered stealer you wold get me, too.

the key issue for me is that it needs to be easy to keep up to date with the recent versions. we produce very frequent builds (sometimes several times a week) and i am looking to automate those as much as possible with gradle. right now, having a single place to publish the apk speeds up the whole process a lot. eventually the updates will become less frequent then the distribution issue can be adressed properly.

you can literally check out the source from github (git clone, gradlew build) and build it yourself. or you can download the signed apk from mycelium.com. of course you need to keep up to date when we release new builds. there will be several changes to the server API while we are in beta.

i don't know enough about the process at f-droid how fast they incorporate changes.  i also doubt that we are elegible because of our license. i think f-droid signs the apks themselves. while highly unlikely any maintainer there _could_ inject any code they want. of course similar things can be said about google play, with the recent APK bugs in the wild. i would personally feel more comfortable with a release signed by the original developers.

i think the optimum way to do it would be for us to provide signed released and f-droid verifies that a certain git tag corresponds to this. i briefly scanned their forums and the process seems highly manual so far.

Regarding the """open source""" via google market issue: could you please make sure the app also makes it into https://f-droid.org/ or explain why this would be inherently less safe? I was just told that f-droid promises verifiability of installed apps but through the idea in here without searching this myself but think it is a big trust issue.

But it might become the standard of crypto coin land.
https://bitmessage.org/forum/index.php/topic,2563.msg4855.html#msg4855 Bitmessage Namecoin integration
Hopefully we will soon do something similar for a Bitcoin client (potentially Electrum)

It is getting much better: https://bitcointalksearch.org/topic/annnmc-namecoin-wallet-qt-with-integrated-name-registration-v375-236375 Namecoin-Qt

I wanted to answer but I will stop trolling now. 

Admittedly it is still early but a man can dream.

thanks

confirmed ;-)

That'd be desirable.

Back to the cold storage!

not sure wether I asked this or if it was answered: where does the change go when spending from cold storage?

it is in the beta channel - if you sign up you have it. (or you build from source)

i have discovered a slight issue with change addresses - almost the hard way.
most users would be unaffected but i think we will not release 0.6.0 as it is now. i will modify how change is handled, and send it back to one of the input addresses (for now). the regular release in the play store will be 0.6.1.
once we have HD wallets we will of course generate a new change address for each TX.

When do you estimate 0.6.0 will be out?

John Tobeys implementation is only "resembling Firstbits" (his words), so I guess you're correct in saying it's different. Wouldn't hurt to ask him, though. He's very responsive and helpful and has probably thought about different (implementation) approaches recently.

I simply have to share this awesome demonstration of cold storage spending 
http://www.youtube.com/watch?v=1pDSzOiFgIk

I also doubt the usefulness of NMC for address shortening. Address shortening is all about usability which is not exactly NMCs strong point.

Setting up a namecoin system for this seems like a lot of work.
Does anyone other than a handfull of geeks use name coin for associating a name with a bitcoin address?  I never heard of it.

My intention is absolutely to add it to the server. I am looking for a way to save development bandwidth by getting inspiration on how to do this right in the first stab.

Seems that firstbits.com has been discontinued, and firstbits.net is forwarding to blockchain.info. Abe seems not to follow the same rules as blockchain.info. I'll start a discussion with SgtSpike & piuk on exactly which rules to use for firstbits.

You might want to consider spending to Namecoin IDs (you can save a Bitcoin address in a Namecoin ID).

Dont you already have the means to implement firstbits in your server?

bitcoin-abe has firstbits functionality. however it seems a bit overkill for your case to setup a bitcoin-abe instance just for that.

couldn't you use blockchain.info api or some publicly accessible bitcoin-abe instance for firstbits lookup?