Fizzisist, I need about $500 a week to pay my life costs, so we need you to go ahead and put together a 60GH/s setup. Nevermind that you're not getting paid or anything.
+1. Can you do all the work while we just watch?  |
|
|
|
I've been working on building client-side javascript apps ( http://brunch.io) and am really wanting to make sure that they are secure as possible. There are people that openly laugh when javascript and security are brought up in the same sentence, but I think they are a bit misguided. Many of the vulnerabilities that have been pointed out to me exist on any website where javascript is enabled, not just on client-side javascript apps. I was researching javascript injection (which many people consider "game over") and had an idea. LOTS of sites use google-analytics. The default code snippit for google analytics loads HTTP if the page is HTTP and HTTPS if the page is HTTPS. This is pretty common behavior for most file requests. So what if I had control of a DNS server? If I modified my public DNS or poised someone's DNS or editing a target's hosts file, could I serve them whatever javascript I want? Turns out, YES! I downloaded http://google-analytics.com/ga.js and https://github.com/scottschiller/snowstorm/ and combined them into one minified file. This way, the analytics still work, but it also snows. I dropped this file into a new folder on my webserver-- google-pwnalytics.com. I then setup nginx to serve both google-analytics.com and www.google-analytics.com (but NOT ssl.google-analytics.com so not all of the HTTPS queries throw errors). Then I configured my personal DNS server to point google-analytics.com to my webserver. I cleared my browser cache and went to one of my own sites that has analytics. It snowed. Then I went to a few sites that I don't run. It was snowing on lifehacker. The number of sites that this attack affects is scary. This attack doesn't get every site, but it got enough that I am concerned. Most attacks are targeted at one site. This one gets every site that uses HTTP analytics. Obviously, having it snow isn't going to do anything bad, but what if the script grabbed cookies? Injected cookies? Searched for forms with a "password" field and redirected input to me? Javascript injection is bad news. There are a few things that can easily stop this attack like DNSSEC and HTTPS. Maybe we could start doing javascript checksums lol. Most people don't do anything though. It also doesn't help that the recommended code snippit from google is affected. If you are building an app that needs to be secure, make sure you only serve 100% trusted code only via SSL. tl;dr... As a web developer, don't trust CDNs for high security sites; serve all your own code over SSL. As a user, be wary of Public DNSs. Use HTTPS everywhere that it is available. |
|
|
|
I got oclvanitygen running on my miner just for fun.
Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8
I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it. I'd rather make coins with that much time.
I would still love an easy way to import these keys besides with strongcoin. I don't think pywallet supports the encrypted wallet format yet.
It doesn't, but you can create a new unencrypted one, import your address, and move all your money out of the encrypted one, before encrypting the new one. Don't know if there is a way to extract keys out of encrypted wallets though :/ or you could use the comandline options and unlock your wallet for 10-15 minutes, enough time to import few private keys with pywallet  Oh I didn't realize that it worked like that. I am going to have to do some experimenting now. |
|
|
|
|
I got oclvanitygen running on my miner just for fun.
Fibonachi: 11235813yoNV9F45KjwRiBYnYFufMunTj8
I was originally going to try for 1123581321, but that would take a few years with just one of my graphics cards trying it. I'd rather make coins with that much time.
I would still love an easy way to import these keys besides with strongcoin. I don't think pywallet supports the encrypted wallet format yet.
|
|
|
|
I don't know about that. Block chains are huge over time. Like, way more than tor can move unless you run a node.
I would download the chain the first time off TOR for sure, but regular traffic is pretty light. That's how I did it. An instawallet is a great site, but it is "Not a bank" Instawallet does not aspire to be a Bitcoin bank and as such can only provide a medium level of security. Please do not store more than some spare change here.
A client running behind tor with an encrypted wallet is much more like a bank. |
|
|
|
I am not sure a p2p stock exchange makes a lot of sense unless there first exist p2p entities whose stocks would be traded.
Otherwise you basically just have a smokescreen p2p system potentially causing customers to forget that ultimately the stocks they are buying are centralised entities they still ultimately have to trust.
Since ultimately it is the specific entites issuing shares that you have to resort to to get your share of whatever it is the shares are of, and whom you have to depend on to issue any dividends that might get paid, this whole p2p overlay on top of it seems like potentially jsut another clever scam/smokescreen allowing issuers to pretty much do like bitcoin itself did: issue tokens they have no intention of actually backing but that might nonetheless get seen as having some value due to there being plenty of suckers out there who will in-effect "back it" by buying it.
It will be like hey, mining costs more than issuing a bunch of shares does, so instead of mining a bunch of whatever kind of coins (bitcoins, scamcoins, whatever) lets just iddue a bunch of shares. In either case we have no intention of backing them, perish forbid. Any value they end up having will be from other people buying them. All we do is mine them (or in this case, issue them, even less work than mining maybe) and put them out there for suckers to buy.
So maybe a distributed p2p corporation system would be a good foundation, so that we have actual p2p entities whose shares we could then worry about issuing.
Maybe that would be quite a similar system but start with the assumption that the whole system itself is one p2p corporation, and the shares offered are shares of itself. Then instead of arbitrary non-p2p entities issuing shares just because they decide to, there could be a whole voting process o nwhether the system as a whole even wants to risk sullying its repution by entertaining the notion of handling company X's proposed shares. DO a majority of the token-holders think the company applying to do an IPO with us is legit? Is it a business of a kind we wish to be associated with? Are out armed forces or police or whatever in a position to seize their assets if they default on something? Whatever the criteria, at least a basic vote by the shareholders (token holders?) of the exchange system itself might be appropriate before willy-nilly becoming an accomplice to the latest new Enron scam by agreeing to do the new Enron's IPO on our network?
-MarkM-
I don't think the P2P part has anything to do with fake companies posting shares and hoping for stupid/scammed people to buy them. That can happen on centralized exchanges too. GLBSE had someone make a fake entity for GLBSE and some people didn't do research and so bought shares. Why would anyone invest in a company that they aren't sure is legit where through a centralized exchange or a p2p exchange? I'm glad to see you are getting this together btc_artist. I think it would be really neat if we could have the current GLBSE assets form the genesis block, but I'm not sure how we could migrate the GLBSE accounts. |
|
|
|
Don't you also need to point the electrum thin client to an electrum server?
I'm pretty sure all thin clients need to be pointed at a server. Hence the "thin" part. There are currently 2 public electrum servers up. Electrum doesn't require giving the server your private keys though, so it is secure. |
|
|
|
|
add "proxy=localhost:9050" (assuming tor is listening on 9050) to bitcoin.conf
If you want to be more paranoid, also add "nolisten=1"
|
|
|
|
Note: I noticed that someone created a direct link from facebook to the tar.gz of version 0.22. In order to prevent users from downloading older versions, I removed the old tarballs from the website. If you want to link to Electrum, please link to the page http://ecdsa.org/electrum, so that users will download the most recent version. Or perhaps provide a tarball that always links to the current stable? |
|
|
|
Is source for image creation available anywhere? Seems author is no longer developing this.
I would like to take this project add cgminer, bring it to current version of debian and some other improvements. Would rather not reinvent the wheel.
Did you try emailing the author? http://www.linuxcoin.co.uk/index.php?page=contactOr maybe look at BitSafe ( https://bitcointalk.org/index.php?topic=46916.20). Both bitsafe and linuxcoin in that both are built on top of debian. It is meant for secure wallet storage instead of mining, but there is no reason why you can't add mining utilities to it. |
|
|
|
|
Looking great. When I get a chance (probably this weekend), I will get it running on my miner.
I'm assuming we pay the bounty once its stable?
|
|
|
|
http://dot-bit.org/HowToBrowseBitDomainsSome of the methods require some installing, but setting your computer to a public DNS does not. This won't support tor resolving, but I'm assuming that's fine for you.
|
|
|
|
|
You guys are making my head hurt. It sounds cool though
|
|
|
|
|
Say I have my client connected to the main server, but then it goes down. Would it be possible to have a client connect to a fallback server?
|
|
|
|
Sadly I wont be able to continue development of the in-browser client (the current web client) as it's beyond my Javascript ability, and I've not been able to find someone else who can move it along. So I'm going to have to either find someone else to do so or find a way around it.
Glad to see you are back and working  If you setup a good enough API, you won't even need to worry about the frontend; anyone would be able to write it. If you build a restful API that returns JSON, it wouldn't be too hard for any third party to write their own clients. I have been working on my own namecoin project, but I think GLBSE is more important. I would be willing to work on a front-end. I prefer python or PHP, but I have recently started playing with backbone.js. I just recently found http://brunch.io/. In a version or two, I think it would be perfect for a javascript client. In fact, a couple days ago I was looking at how you were doing auth and started to implement a very similar system in a brunch site. |
|
|
|
The above discussion suggests a technique for two-party escrow without transaction scripts. - Bob wants to sell Alice goods for Bitcoin payment.
- Alice generates key pair (a,A) and sends A to Bob.
- Bob generates key pair (b,B) and sends B to Alice.
- Alice sends payment to the address corresponding to A+B. At this point, neither Alice nor Bob can spend the funds.
- Bob verifies payment was sent to address A+B and ships the goods to Alice.
If Alice receives the goods as expected, she sends 'a' to Bob. He uses the private key a+b to sweep funds to his own address. If Alice never receives the goods, she withholds a and the funds are permanently lost. If Bob wants to refund the payment, he sends 'b' to Alice and she uses the private key a+b to sweep funds to her own address. If the transaction goes well and all messages are public, third parties can verify that Alice fulfilled her part of the deal. This could form an part of a p2p exchange with partially-provable reputations. I like it! Reading stuff like this makes me want to delve deep into EC math, but I just don't have the time. The only problem is if Alice receives the payment and doesn't transmit a, then Alice has the goods and Bob has no funds. Alice doesn't have the funds either, at least. I guess if you want that level of assurance, you can use scripts. |
|
|
|
I have two problems with bccapi 1. The server is not open source. I asked the developer about it, see here: https://bitcointalk.org/index.php?topic=46493.msg571018#msg5710182. The server needs to know you. It needs to store an account with your addresses, because it keeps track of your transactions as it downloads the blockchain. In other words, its database works just like bitcoind, whereas the Electrum server behaves like a Blockexplorer database These two facts create a situation where users are tied to a server that belongs to a single individual. Even if Jan decided to open-source his code, the fact that users need to be known in advance from the server does not favor privacy or freedom of choice. This is the reason why I decided to write Electrum ( https://bitcointalk.org/index.php?topic=46493.msg585227#msg585227) This is the reason why I am interested in using Electrum. |
|
|
|
|
Show Posts
