The FriendlyPay app is now available on the appStore for iOS device: it's a mobile version of instawallet, using instawallet.org as backend.
Tested this app. now. Good work, extremely simple like Instawallet itself, I like it, this has great potential. |
|
|
|
|
Interesting.
How small are you thinking a final version maybe? As small as a USB stick with 2-line display?
I think for btc savings (large amounts) having just a small, network-isolated, piece of hardware that does nothing else but store keys and sign transactions is a very promising concept.
|
|
|
|
Good find. The beat goes on ... |
|
|
|
|
Well millibitcoins are already being used regularly in some places ... Ogrr, bitcoin advert clicks, etc ... so i'd say at least 3 decimal places.
|
|
|
|
to avoid running bitcoind, the wifi router could forward the transaction to an Electrum server, and get confirmations from it.
I am interested in this project and I can provide technical assistance towards such a solution.
This had crossed my mind also. It is an ideal application for a lite client, like ThomasV's Electrum. Maybe blockchain.info and the iOS app has some merit also. Maybe a viable business model is to provide multiple bitcoind backends on remote servers, use stratum to communicate with the wifi routers lite clients and take care of install, billing, maintenance, etc for anybody wants to get paid for one-click install public access wifi sharing on their router? The business gets a small cut from many (maybe many many many) routers and the router/access owners get all the "s/ware bitcoin stuff" just done for them and a bitcoin check in the mail every month. Kind of like a wifi router sharing pool. |
|
|
|
Cool. the iPhone FriendlyPay app didn't come up when searching the App. Store  An iPhone app is available worldwide, for free, in the AppStore, it's called FriendlyPay when it is available it needs to be put up in bright lights somewhere .... InstaWallet for iPhone big, imho. Post it in the comments to the latest Forbes story regarding iPhone bitcoin Apps for example .... |
|
|
|
Has anyone else here tried chatting with Cleverbot? http://www.cleverbot.com/It is an interesting way to waste some time ... but is it wasted if the bot is learning off the interaction? Curiously the longest it took to answer was when I simply said to it Cleverbot? after a long, long pause it simply said ... Yes. Maybe a fluke answer but blew me away. Was spooky but raises the question about the whole Turing test. If the bot did become self-aware, which to me seems like a pre-condition to passing the Turing test, then it must be able to engage in an act of deception to fool a human into thinking that they are chatting with another human when in fact they are talking with a self-aware bot. Is the Turing test even fair for a self-aware bot? Do we want to encourage deception from our bots? I think Cleverbot needs conversation with intelligent, honest humans to advance like a child being parented ... probably not what it is going to get with your average on-line chat. |
|
|
|
|
BioMike I sent you a PM regards Operation Fabulous.
|
|
|
|
Unless you want to argue that fungibility is not related to anonymity of digital tokens, or that fungibility is not an important property of money.
Of course fungibility is important. But fungibility isn't all-or-nothing, and, in my humble opinion, it isn't all-important. Refusing to accept dollar bills or bitcoins that you believe were obtained illegally makes them less fungible, but so what? It's the right thing to do. As far as singular transactions go, one on one you are right, it is the right and moral thing to do, but the overall effect on the currency system itself will ultimately be fatal. I. e, how many transaction steps down the chain do you think it is appropriate to re-integrate tainted coins? You cannot hold every person who uses those coins from then on responsible for the sins of the the previous users of the coins. After a certain number of transaction cycles, any digital token system that has endless tracing trails will end up with money that was at any point involved in "illegal activities" contaminating the whole system, locking it up. Much like we are witnessing with the current central bank fiat digital chits that have recently implemented detailed tracking maybe? In the end, money is an information technology and like any other technology, amoral, bitcoin cannot be held responsible for the activities of the users of the technology. In my opinion, it is not a function of the money to know if it has been involved in "illegal activities", you obviously disagree. But it is well known that good money is fungible and you would be going against all evidence to the contrary to implement successfully something that wasn't. The free market will decide as soon as we get a truly anonymous (digitally fungible) competitor unit into the marketplace, it maybe a spectrum of anonymity is acceptable and it comes at a range of pricing as Segio is suggesting. Out of interest, given the choice and all others things being equal, which would you rather hold a pseudo-anonymous digital currency or a totally anonymous currency? |
|
|
|
|
Trying to gauge interest for proposed bitcoiners meet-up in Auckland;
When:
Saturday 26th May, 2:30pm
Where:
Horse 'n Trap, Mt Eden (near the old shot tower, prison, etc)
or
Claddagh irish pub, Newmarket
Reply on this thread, PM me or just show up. Also open to suggestions for alternate (better be better) location or date/time.
|
|
|
|
Ok, thanks for your replies, for me it was important to get to the bottom of the physical handling of the keys. One final line of questions, your tutorial recommends "Load Armory on the offline computer" http://bitcoinarmory.com/index.php/using-offline-wallets-in-armoryDo you have a recommended method for this? Is it the same method for Armory s/ware updates and dependency updates, etc? Should the offline computer have OS installed from a DVD/CD and OS s/ware updates done via USB? I mean how rigorous is the "offline" status of this machine? Like "absolutely never been connected" ... or something less so maybe? |
|
|
|
So out of interest, what is the basic strategy for Armory's physical handling of wallets?
Specifically;
1) are unencrypted private keys ever held on disk (or only ever in RAM)?
2) how are any old copies of wallet files that reside on disk at any point deleted/erased?
i would just use an offline wallet which is why i chose Armory to begin with. Well thanks for the useless, random, tangential comment. Offline or online is not relevant to my question, if you don't realise that yet. I think his point was that the questions you ask are irrelevant if your computer is offline. Stored in RAM or HDD, encrypted or not, doesn't really matter. The only thing to worry about is eventually discarding it, but if you stored any significant coins on it, ever, thermite is the only real solution  Not true, I was considering every possibility. One particular offline example, thief comes in and physically takes your "offline" drive (and contents of house safe). If people are going to feel comfortable about storing life-savings on offline (or online) drives at home the stakes go up. You must have considered physical loss surely? |
|
|
|
I don't particularly think that anonymity is all that important a property I'm inclined to disagree. Anonymity, in the context of money, is strongly correlated to fungibility, e.g. "I don't want those dirty coins from XYZ terrorists, pornographers, bogey-man, etc." Already Mt. Gox and others are using "green-list" btc addresses, demonstrating how fungibility is lacking on bitcoin. Good money is fungible, therefore in the digital realm it needs anonymity to fulfill that important property. Unless you want to argue that fungibility is not related to anonymity of digital tokens, or that fungibility is not an important property of money. |
|
|
|
So out of interest, what is the basic strategy for Armory's physical handling of wallets?
Specifically;
1) are unencrypted private keys ever held on disk (or only ever in RAM)?
2) how are any old copies of wallet files that reside on disk at any point deleted/erased?
i would just use an offline wallet which is why i chose Armory to begin with. Well thanks for the useless, random, tangential comment. Offline or online is not relevant to my question, if you don't realise that yet. |
|
|
|
Right. I'm just a little concerned that since on most OS "delete" actually just changes (removes) the file header to make that space available for new writes and the file data is hardly ever changed then there is a trail of remnant wallets all over the place waiting for a disk recovery tool to come along. Even remnant encrypted wallet data may become a target if valuable enough.
Unless someone is assiduously creating new wallets and moving all their coins to the new wallets as they go then wallets that are moved around need to be aware of where all the old copies (including remnants) have been left behind, since any of those copies, live or "deleted", will potentially be a vulnerability. I would make "only secure delete" a policy of any wallet handling tool.
Agreed. I just feel like there's very little I can do to accommodate this, besides making a good-faith effort to overwrite the data in place instead of just doing a vanilla delete operation. As I mentioned in my previous post: this attack vector is basically nil if you wallet was born encrypted. Any users with any significant amount of money that don't encrypt their wallets: well they are probably at greater risk of other attack vectors. Perhaps I'll add a warning (along with the millions of others) which warns about "residue" wallets even after deletion. I don't think there's anything else I can/should do about it. Unless you have recommendations...? Fair enough. Small recommendation, maybe you could also have a warning for people importing currently unencrypted wallets (or at any time previously unencrypted) to transfer the contents of these wallets into encrypted wallets. A warning to "Begin as you mean to go on" so to speak. Foxpup: The "srm" (secure remove) tool in Linux doesn't require root access nor knowledge of the filesystem. The default 35 times overwrite is over the top but the -dod (7 times) or -doe (3 times) flags are prudent security. https://en.wikipedia.org/wiki/Srm_%28Unix%29 This would cover Unix, Linux and MacOSX users, but it introduces a dependency. |
|
|
|
|
Right. I'm just a little concerned that since on most OS "delete" actually just changes (removes) the file header to make that space available for new writes and the file data is hardly ever changed then there is a trail of remnant wallets all over the place waiting for a disk recovery tool to come along. Even remnant encrypted wallet data may become a target if valuable enough.
Unless someone is assiduously creating new wallets and moving all their coins to the new wallets as they go then wallets that are moved around need to be aware of where all the old copies (including remnants) have been left behind, since any of those copies, live or "deleted", will potentially be a vulnerability. I would make "only secure delete" a policy of any wallet handling tool.
|
|
|
|
Interesting.
Do you cover the specifics of any total anonymity possibility for MAVE? (I didn't see it briefing through the papers).
No. I specifically left Total anonymization out of the MAVEPAY paper, since anonymization gos against performance in every protocol I´ve seen. MAVEPAY aim is to have the best performance, and so pseudo-anonymous transactions are more expensive in MAVEPAY and total anonymization is not granted by the protocol. I´m working on the paper of a system with total anonymization as the design rule. I´ve already designed it. Nevertheless, it uses a lot of PK crypto (signatures, trapdoor mixes, universal re-encryption, zero knowledge proofs). I think its performance would be 10 tps (and the bottleneck would be hard disk block chain storage). Sergio. Ok, thanks for clearing that up. I had read your earlier blog posts and assumed that MAVEPAY was "the one". I'm more interested in the total anonymous system is why I just briefed through MAVEPAY papers. Seems to be obvious, in hindsight, that there will be a trade off between anonymity and system performance, yet interesting never-the-less, once the details are fleshed out. |
|
|
|
|
Show Posts
