i have a proof of concept/platform for creating transactions using plain text/files/QR codes using the BitcoinJ client. The transaction can be forwarded from a relay client, which could be anywhere with an internet connection. I've been working on it in my spare time for the last couple of months and I've hinted at it on the forums every once in a while. The actual transacting is a bit light on testing and it needs more work on the receiver/relay side. Some of the bigger issues I haven't even begun to address are double spends attempts (accidental or intentional), transaction revocation, and other fun stuff I probably haven't thought of yet. I've been spending the last few weeks setting up tools in preparation of opening up development and doing an initial public release. Look out for in the coming weeks/months.

I like this idea. I don't like the idea of biometrics though. There are lots of discussion about why linking biometrics to anything important are a bad idea (I like to use "Demolition Man" test).

I'm working on something that will partially fill the solution you are proposing, but I may borrow some of your ideas to make it better. I've been working on it in my spare time for over a month now, it's a similar concept but think QR codes/web cams instead of flashing screens. It's a bit clunkier but you can do it with commodity hardware. I believe there is just one more critical bug before the Proof of Concept is complete and it starts moving toward Alpha quality software.

I know it can be fun to roll your own encryption, but just don't do it. There are just so many attacks possible that regular folk like you or I just don't understand. Until the algorithm AND the implementation have been seriously vetted, it's really just security through obscurity. I'm not sure many around here could take a serious stab at vetting crypto. Do not take comfort in obscurity either as it is rarely obscure enough to be secure. If you are okay with taking risks, that's fine for personal use, but please do not distribute whatever you are planning. You would be doing a great disservice to release something you rolled out yourself, there's a reason the Bitcoin devs are taking their time with the wallet encryption that didn't make it into the last release (0.3.24)

I wouldn't say zero risk, that may be a staple of Bitcoin, but not for the periphery services. I like that they are offering this service, and they certainly seem to be committed to achieving that end, but time will tell if there are charge back risks.

Not me. I lost either $100 in the postal service or 140 odd BTC in a scam called bitcoin4cash.com, take your pick. What a welcoming way for my first Bitcoin transaction to go, way back in April. I tried contacting the guy, the only solution he could come up with was effectively "wait for it...wait for it..." until the order got "cancelled" by an "automated system" and he started ignoring my mail. It would have been worth resending for me, but how can I resend to a guy like that? I believe his alias is "Mad Hatter" on the forum.

Ahh, sorry, well it doesn't seem to change much. If anything it looks a bit easier. There is a http rewrite module for nginx

The most robust rule that applies is probably something like this

The wiki says using try files are a good idea, so you might need to look into that if you want better scalability. HTH. Hopefully I didn't miss any other obvious information you've already stated.

I've dealt with redirects that were similar in complexity. it shouldn't be too hard if you are using apache, you just need to use the rewrite engine in the .htaccess file, i think.

using google I would say you'd want something like this. just for reference i altered the following example which seemed to be close enough to be workable

as I mentioned earlier in the thread I'm certain it is just the twitter feed, at least with respect to firefox. it's pretty low priority in any case. having a redirect for the www sub-domain to primary domain would be a smidgeon higher on the list for trivial issues.

if it were parts for Yet Another Mining Project, I'd wholeheartedly agree with the decision. i want to see original business ideas receive loans/investment from IBB. also I believe they require something in the way of a business plan.

okay i stand corrected. it was a case of PEBKAC, apparently I still don't fully understand git. the latest commits weren't showing up in the tortoise-git log and doing fetches didn't help either. one of the descriptions of pull I had read made me hesitant to try that again. it's working for me with the latest commits from july 28. thanks.

from what I can tell it's because openssl doesn't trust the certificate. I tried adding it to the windows trust store and that certainly did not help. i didn't try very hard, but I wasn't able to find the necessary openssl command. looking at the crt file, I didn't see a trust chain in it, so that might explain why it's not trusted.

In some ways, plain text is better than a false sense of security, obviously in a pragmatic way it is not. But, why use half measures when the business case for rudimentary security is so easy? You've already done 90% of the work implementing SSL. You can get an entry level signed cert basically for free. One case of fraud due to MITM is going to cost more than a signed cert. You can always upgrade your cert level if there's a business case for it. It's a case of penny-wise, pound foolish. Don't cheap out when you are dealing with money that belongs to someone else. Certs should only be the first step.

@nefai i know you're being sarcastic, but that warning is coming from twitter. I wasn't getting that warning until I enabled that script

@alfred we know, this thread is not directed at glbse in any way any more, at least I hope it's not, they've taken a step. too bad the www subdomain throws a hissy fit, though Nefario could always just create a re-direct.

I don't disagree with most of what you or nafai said. If SSL was JUST line encryption, I would accept encryption is better than no encryption. However, it is not, tying it to identity verification is unavoidable. As someone that tries to pay attention to the contents of self-signed certs I feel helpless verifying the identity behind it. I know self signing is "good enough" more than 99% of the time, but with these thing you need to be on top or you will run inevitably run into that less than 1% scenario at a really inconvenient time. I doubt many service providers would eat the cost in the rare case where one of their customers mistakenly accepts a spoofed self-signed cert and are taken advantage of.

I think it's disingenuous to say that signed SSL identity verification is worthless while also saying that the encryption provided by self-signed certs is good enough for production use. Show me one white paper that recommends choosing a self-signed cert over signed cert in a production environment as a best practice and I'll eat my hat. Yes someone could hack a cert authority and issue a valid cert for something spoofing your server. The point is they don't need to hack anything to impersonate a self-signed cert.

Anyway, glad to hear you started using a signed cert Nefario.

Dude, they are a start-up, they need to pay off their initial costs, streamline their offerings, and above all turn in a profit. I don't know bit-pay's fee structure, but if they make it easy for merchants to start using Bitcoins by providing a great service, it's good for everyone. Also, from what I've heard on these forums the credit card companies basically make money every time there is fraud by charging merchants out the ass, so they aren't using their percentages primarily for that purpose. There's no reason competition can't fix the fee "problem" as usage goes up. From what I remember they offer Bitcoin directly to cash equivalent conversions, so those definitely have real costs that need to be covered. Some form of fee seems reasonable at this point and if merchants are willing to pay, that's their prerogative.

I've added a boilerplate page to the wiki and linked it to the "Shopping Carts" category. I didn't take the time to fill out any of the content. I might squeeze in some basic info before I go to bed.

https://en.bitcoin.it/wiki/Bit-pay

Changing browser behavior is pointless, it is the correct behavior for the current state of SSL. Self-signed certificate are worthless to typical end users unless you have some sort of third party that can vouch for it. An average user has no way of verifying the certificate is issued by whom they intend to communicate with. This is a HUGE problem for wireless connections. The only way self-signed certificates would be practical is with a web-of-trust/plugin as some have linked in this thread. I haven't tried such plugins despite thinking they are a good idea and knowing about them, a regular user doesn't sand a chance evaluating a certificate.

i accept self-signed certificate fingerprints all the time, but I assume the servers I connect to have not been compromised and that I'm not being MITMed. To expect ordinary users to blindly trust a random certificate from a random server is reckless. At least with signed certs you have an iota of assurance which is much better than nothing, cost has nothing to do with the issue, there are free signed certs out there.

Complaining that signed certs are a protection racket and bringing conspiracy theories about snooping just shows you don't understand this issue as much as you think you do. If there are back doors I'll appeal to authority in the absence of any real evidence. Regardless, setting a higher bar is necessary, if you can get browsers to make self-signed certs idiot proof, then I might accept them as superior to signed certs, until that time it is reasonable to expect signed certs.

a number of people have raised this to Nefario, myself included. he was initially reluctant to use a signed cert but he has conceded that using a signed cert is something that needs to be don. after making that decision, he said he was having trouble getting a signed cert while he was living in China, but now that he is in the States I'm sure it's on his to do list after settling down and taking care of some more pressing issues with service.

The closest thing there is right now is the "asset contracts" page, which you can get to when you click on "Start Trading" on the main page. It's not very the greatest but hopefully Nefario's changes on Monday will give us something better.

Might be a good idea for a spending account, I don't think it would be a good idea for a savings wallet. The biggest problem is there is always a chance of key loggers and malicious code could also target the keepass software.

I'm looking forward to looking at certain parts of the source that I'm interested in. This is definitely a boon for people like myself having trouble with the sources of the desktop client. I spent a good amount of my weekend just trying (and failing) to compile the desktop client. This should have the code I need to move forward with a project I've been thinking about and will hopefully be a part of this client in one form or another in the future.