If you have any other/better ideas to help preserve fungibility then we need to hear them now! Please!

It would have been WAY more profitable if the Robot had done the EXACT OPPOSITE of what it did! A little upsetting in these volatile times.

The hackathon thread inspired me to share an idea for an Android app that should not take more than a weekend to code:
I want an Android App that allows me to run deals with physical places to accept bitcoins into my wallet. The app should keep both me the bitcoin junkie and the what-is-bitcoin-merchant updated of our mutual dept.

• The merchant should be able to type in the price in any currency (google converts to USD, bitstamp converts to BTC, later updates will support formulas using vwap, min, max, etc.)
• The app should be able to show a QR-Code with amount
• The merchant should know (sound) when the bitcoins arrived (blockchain.info has an api for that, later a dedicated server could take over. This server would not need to know anything about the users)
• The bitcoin junkie should also get alerted of his updated debt, maybe via a mail ("check your balance"-ping. transaction timestamps and historical exchange rates should allow to come to coherent conclusions both end without writing details into these mails).
• When the merchant receives fiat from the bitcoin junkie, he should be able to tell the app.

The bitcoin junkie part of the app should be able to keep track of more than one merchants.
Improvements would be to incorporate fees for fiat delivery delays (parties should be able to agree on for example "weekly settlement is free but any day delay costs 1%), limits on the amount of bitcoins to be bought ("I help you get started with bitcoin but will only buy up to $200 per month"), merchants should be able to link to several bitcoin junkies, too (maybe the one would handle big volume but the other would take no fee etc.).
It would help people to accept bitcoins in a bitpay way so they never actually touch bitcoins and don't need to worry about volatility or regulations as in their books it's just the bitcoin junkie who owes them fiat. I'm interested in any feedback as I'm an Android developer I'm thinking of doing this myself but would be in to participate in an open source project or would be happy to see others get this going as an open source project.

This is not meant to run as one big branded service but as an enabler for many thousands of independent "providers" that would operate under the radar. It would also primarily be meant for markets where there is no good bitcoin infrastructure yet.

Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools.

Some day you may disagree some actions they will take. But you can do nothing, just like me now.

This is true, but we were discussing wallets fairly specifically.  You points about privacy are good ones.  Theft would take the form of a trojaned JS (or whatever) so it is not trivial and a inputs.io style theft would not be very possible.

I only trust what I can afford to lose to anyone.  A service which is demonstrably more complex to exploit will earn more of my trust and I'd potentially maintain a bigger balance there.  I use exclusively on-line wallet these days because the data rate needed to support a full node exceeds my monthly bandwidth allowance and my secure computer does not run Java.  I'd run something like Multibit (albeit with distaste) if I could compile it myself, but even then I'd still prefer an on-line wallet for spending money.  I don't mind hooking up to a low funded on-line wallet with my Android and Windows machines, and I personally am not terribly bothered by privacy issues for a majority of my activities.

I would prefer methods with a privacy focus out of principle.  As the coinjoin and other methods develop I'll support them for political reasons more than anything.

Which is why we can't nice things anywhere . Scammers always makes things more challenging.

If the service used UCE (User Controlled Encryption) then the results of a service takeover attack would (or could) be minimal.  The attacker could not obtain the BTC, and the user could, with effort, re-claim it.  In my understanding of things, blockchain.info wallet is basically of this type.

Interestingly, cloud storage and many other forms of data transmission and storage (e.g., messaging) are trivially and easily protected by these methods.  Brazil is on some kick to 'keep data local'.  This is absurd.  Data managed by UCE can be stored and transmitted across untrusted mediums safely and trivially.  There is a media blackout on mega.co.nz at this time, but the service they provide seems to be working well (and they take Bitcoin!)  I'm looking forward further developments by that organization.

In my opinion, a resistance to using UCE is attributable to about one thing and one thing only.  Namely, the provisioner of the service wants to, or needs to, have the option to compromise the data.

Who would willingly participate in a CoinJoin transaction if they already have clean coins?  Naturally the inputs to these CoinJoins are going to be *very* red.  Participating would be a bad idea unless you've got some extremely dirty coins.  These coin mixers will be full of the filthiest of filthy coins.

I don't see much of an advantage to mixing around red coins - you still get back red coins.  So you might go from having 100% DPR coins, to having new coins that are 30% DPR, 30% inputs.io hack, 30% CryptoLocker, and 10% clean from whichever fool decided to donate their clean coins to the sea of red.

This scheme only seems to obscure the history by mixing transactions, but it doesn't reduce the red tarnish for the average participant.

Where and how did you get a claim ID number? Was it submitted during the initial claim process or later during the dispute process? When I filed my three claims back in early April when the claims process started, I don't recall seeing one, nor received one via email. The only thing I recall during the inputting of the three claims is that after I did such and clicked submit (send, etc.), an identical claim page was generated, thus nothing worth taking a screenshot of, but safely assumed they were submitted properly.

To answer your last question, probably not.

The caveat is mainly in place to make sure endowments are not allocated to NPOs that are clearly attached to a particular religious organization. For an example, there may be a Baptist Church in Atlanta that has a separate 501(c)3 set up to garner donations for some cause of which does a phenomenal job with their non-profit. In that case, it would not qualify. Realistically, there are thousands of such caused set up by churches, mostly at the local level, and it's these that we opt to not include for consideration.

I hope I addressed your question/concern to your liking, but if not, please let me know, and thanks for the opportunity to letting us do such, Kluge.

~TMIBTCITW

The fight club has two rules, Instawallet had only one : "He who has knowledge of the secret URL is the legitimate owner of the funds".


Wait a second, you made your wallet URL public before the fucking claims process was even started, and then you come bitch about us not paying you?
You jump to conclusions right after we get compromised, throw shit at us before we're even done piecing the claims process together, act like an idiot by voluntarily publishing your wallet URL on bitcointalk and then you come complain that handling your claim isn't as straightforward as the others?

Look in a mirror and get real, you shat on your own feet.

The correct and logical course of action now becomes crystal clear, we'll pay both claims half of the outstanding wallet balance.

For the record, gizsmo pretends to have a claim even though he is not making it possible for me to resolve it by providing the required information: claim number, walet url and amount (even after me asking him about it via PM).
He is challenging the claim process because he obviously has no concept of what it means to run said process.
He is only waving a claim number so that no one can see its minute amount.
Such a minute amount would reveal that he is simply on a manhunt.
Baby giszmo (Leo whatshisname) is behaving like an asshole because he does not know that a business can be made of hard working, dedicated people that don't take calomny so lightly.

The reason you have not seen your payout is simply that you did not approve the proposed payout.
As explained in my previous posts, we need discharge from the people we pay out otherwise there is no way to remove the liability from our books.
The discharge is required because the database has been tampered with: even though it may be minimal and partial, there is a non zero probability that the proposed amount does not match the expected amount.
I am posting this here for the last time because I realize the thread has been polluted by a few assholes (tvbcof, giszmo, etc) that have nothing else to do but waste everybody else's time, making it difficult for claimants to find the information.
A sendmany transaction will be sent  in january to those who filed a claim on time but failed to approve their payout so far.
To approve a payout, simply visit your wallet page (do not forget to type https://www.instawallet.org/w/yourwalletsecreturl in full). Thanks for your cooperation in getting these claims resolved.