Can you do a "1-of-1 or 2-of-2" transaction, where either the overseer spends the coins, or both the overseer & the holder spends the coins?
You can do 2-of-3 (overseer holds 2, so can always spend, you hold 1) instead to accomplish the same thing. I suppose having the overseer put transactions in the block-chain that everybody can see might make you and the people you're paying trust them more... Thats an interesting way to do it. Might as well just give your coins to the overseer though as they don't need you. Maybe have 2 separate overseers? Seems strange and I'm not sure I see a use-case. |
|
|
|
I was developing my own bitcoin version, and I need to know. Can someone provide a list of clients that are trusted clients, to always be up, and at the latest version, 24/7. Something that would be hard coded into a bitcoin client.
trusted peers are NOT the way to go. and running the latest version is not possible as it is a opensource project with forks, and alternative clients trusted peers are what bitcoin uses if it can't hit the IRC channel. What do you propose instead? I think he means latest version of the protocol, not the client. These two things get confused all the time because they are both called "bitcoin." |
|
|
|
Nobody said that all nodes are created equal. I would trust people with things to lose (e.g. established Bitcoin business such as Mt. Gox).
I would connect my client to servers run by the top 5 Bitcoin businesses.
Send queries and transactions to all 5. If any one of them disagrees, disregard its results.
It I can't get a consensus of 4 to agree, there is a major problem and I fail the transaction.
Use SSL to avoid man in the middle.
If you're running a business that's large enough to really be paranoid about Mt. Gox trying to scam you by falsifying TX data, then simply run your own server - this whole Overlay Network is targeted at end consumers and small businesses / webapps that don't have much to lose.
I plan to run a website that will probably never pass 100 BTC. Even before multiple server support, if I only rely on Mt. Gox server (or slush's server, or whatever), then Mt. Gox and slush have more to lose than by double spending against me.
This. |
|
|
|
I'm not saying its 100% secure. I'm saying it probably can't be but also that the attacks are not very dangerous. |
|
|
|
If you don't have a copy of the block chain, anybody running the server you're talking to can "send" you coins and then take them back with total impunity, simply by making sure that a transaction sending those coins to themselves is "mined in" to the blockchain before they release the transaction that looks like it's sending them to you.
Um. How is the server supposed to send those coins to themselves? EDIT: They can only send you coins from them which severely limits the attack. They can't change someone else's payment to you because of the hashing done. I also don't think "mined in" and simply can go together at the current difficulty. Can you name a client-server model that DOES NOT require trust? This problem is also removed once the client can talk to multiple servers.
This is dangerous " cargo cult security". It does nothing to prevent man-in-the-middle attacks (my ISP attacks me) and merely shifts the problem elsewhere. What prevents somebody from renting 100 cheap VPSes and running the server software on all of them? Worse: botnet operators. I don't get what "cargo cult security" has to do with this. Stick the protocol and SSL and you can't MITM. You are essentially saying we are vulnerable to an attack from a large number of servers. You know what else is vulnerable to what is often called a 51% attack? Bitcoin... I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able.
With all due respect to slush, he shouldn't provide a "defense"; he should address these issues in the design document by explicitly stating the trust model. The "defense" would be that the protocol doesn't need modification as there is little need for trust in almost everything the server does. Like I and others have said: This is a client-server model; not a decentralized model. You are giving up 100% security for ease of use. Once this is more developed, we could make it easy for everyone to run a server of their own on their home network. Then people could run one server (they already run atleast one node) and use thin clients that only connect to their own trusted server if they want to be paranoid. |
|
|
|
If the protocol is done right, zero trust is required
Just saying that does not make it true. Please describe a possible attack vector. I provided a few |
|
|
|
I'd love to see what someone's cgminer.conf file for a 5970 looks like.  I'm trying to learn about all the options in cgminer for a 5970, and I'm a tad bit lost. "intensity" : "7,7",
"gpu-engine" : "0-830,0-825",
"gpu-fan" : "10-85,10-85",
"gpu-memclock" : "300,300",
"gpu-powertune" : "0,0",
"gpu-vddc" : "1.050,1.050",
"temp-cutoff" : "95,95",
"temp-overheat" : "85,85",
"temp-target" : "75,75",
Thanks. How many MH/s do you get with that setup? GPU 0: 73.5C 4344RPM | 380.4/380.7Mh/s | A:94 R:1 HW:0 U:5.00/m I:7
GPU 1: 70.0C | 384.3/377.2Mh/s | A:96 R:0 HW:0 U:5.11/m I:7
I'm playing with my rig so I keep restarting cgminer. I've got another card in the rig; these are just my 5970 GPUs. It is in a full tower in an air conditioned server room, so your rig might run hotter with these same settings. |
|
|
|
Uggh, Alright, Im in, I'll use the epic CGminer without a GUI.
It's just such a pain in the ass to learn a new dictionary of commandlines
is thier a lovely noobfriendly guide? Or is it simple enough to figure out with the info provided on the front page
i need to read more
cgminer's command line was way easier for me to pickup than some of the other miners I tried. You can also build the config completely inside the miner and not worry about flags. I highly recommend using a config over starting cgminer with a ton of flags. "Q: GUI version? A: No. The RPC interface makes it possible for someone else to write one though." Yeaaahhhh thats where im going to need help. So far, After i hit pass the whole CGminer window (win764bit) just spews Something down then goes Blank Oh windows... I'm sorry |
|
|
|
Uggh, Alright, Im in, I'll use the epic CGminer without a GUI.
It's just such a pain in the ass to learn a new dictionary of commandlines
is thier a lovely noobfriendly guide? Or is it simple enough to figure out with the info provided on the front page
i need to read more
cgminer's command line was way easier for me to pickup than some of the other miners I tried. You can also build the config completely inside the miner and not worry about flags. I highly recommend using a config over starting cgminer with a ton of flags. |
|
|
|
Why do you trust "the server" (and the person running it, who I assume is not always yourself)?
How do you know you're even talking to "the server" you think you're talking to (no man-in-the-middle)?
I am pretty sure that all client-server models require trust that the server is not lying. I can't think of any that don't. However, there aren't too many things that a malicious server can do. Why do you trust all of the nodes you connect to? I'm pretty sure that most of the same protections to make sure peers aren't lying to you are available to a thin client. For example: A transaction's input contains a signature that can't be faked (if they can, we are all f***ed, thin client or not). If a malicious server gave you a fake input, a simple check would show you it is fake. Since you generate and sign outgoing transactions yourself, there is no chance of the malicious server redirecting your coins to another address unless maybe that address is retrieved from a malicious firstbits resolve where they happen to have a collision. This is a potential problem with firstbits in general and not specifically this protocol. http://firstbits.com/ could make addresses for the most commonly requested addresses and return those instead of the real ones (if they wanted to be thieves) or if the firstbits were short enough, they could generate a collision on the fly. Not sure what we could do to prevent this problem besides letting people know that for utmost security they need the full address. One thing I could see a server doing that would be harmful is not relaying it's clients transactions. Right now, thin clients only talk to one server. This wouldn't be too hard to detect as the person you are sending to would probably mention that it hasn't been received. People are also talking about getting thin clients to communicate with multiple servers which would remove this problem. I think transaction broadcast services will be important for anonymity given some of the IP tracing I've seen. Another problem might be if the server does a double spend against one of it's clients as they could be kept unaware of the real transactions on the network. This problem is also removed once the client can talk to multiple servers. These are basic, fundamental security questions that have been widely known since before SSL came into use. If the designers of this new protocol don't think they need to be addressed, that concerns me.
Run the protocol over SSL and you don't need to worry about MITM. Then, only a malicious server is the problem. If we have a network of servers of running this protocol, some of the problems I mentioned above (like holding transactions) would require a 100% attack (which is likely much harder than a 51% attack ). I'm not sure how we should handle what happens when a malicious server is detected. That definitely needs to be figured out soon. I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able. |
|
|
|
Excellent job, any chance we could get a download-able version?  There is a way you can do this on your computer, but I forgot the simple steps. It was one of those YouTube tricks, one I've used a couple other times in the past for other non-YT videos. Given a few minutes of research, I could possible find that info and be able to rip it from his site and have a copy on my computer. I think a clickable link would be much simpler and is likely trivial for Matthew to add to the site. |
|
|
|
I'd love to see what someone's cgminer.conf file for a 5970 looks like. I'm trying to learn about all the options in cgminer for a 5970, and I'm a tad bit lost. "intensity" : "7,7",
"gpu-engine" : "0-830,0-825",
"gpu-fan" : "10-85,10-85",
"gpu-memclock" : "300,300",
"gpu-powertune" : "0,0",
"gpu-vddc" : "1.050,1.050",
"temp-cutoff" : "95,95",
"temp-overheat" : "85,85",
"temp-target" : "75,75",
|
|
|
|
This is cool, but I couldn't find any mention of the trust model anywhere in this thread or the design docs.
If you keep a copy of the blockchain, trust is simple: you trust the longest chain.
If you aren't keeping a copy of the blockchain, you need to find another answer for this question.
I'm not saying it's impossible, though I am suggesting that it might be the most difficult part of this project (certainly more difficult than choosing wire protocol formats!). I'm a bit worried that it isn't being addressed. Or maybe I just missed something.
There is a server that sits on top of a patched bitcoind which of course has the blockchain. The thin client simply uses this protocol to ask the server the balance or to sign transactions relay signed transactions or w/e. I don't see anything that needs to be addressed. |
|
|
|
block_tx 31386 31603 after just over 3 hours. My VM host was acting up for a bit and not giving the guest it's full CPU, but it seems to have sped up now.
sorry for off-topic. I switched to postgres due to mysql performance-issues. it _is_ faster (in the bitcoin-abe case at least) Well I was wanting an excuse to play with postgres, but I think right now is in the middle of too many other things. For now, my server is still running at max load with mysql. When I do get it up, it will be at electrum.stitthappens.com (might as well change redemerald to my real name now :p ) and the hidden service will be at esvua6k2gzjj64ad.onion |
|
|
|
|
Total time logged in: 4 days, 20 minutes.
|
|
|
|
I'm excited about bitcoinjs. I am going to experiment with putting webcoin into phonegap. That gets rid of the problem brought up in the video of the server being compromised and distributing malicious js. The attacker would have to upload a modified app and then the target would have to update their phone to the compromised version.
The split key idea is interesting. I really want a thin client for my phone. Your JS library and accompanying code will be very useful.
Please keep me posted on your efforts. I realize that BitcoinJS' documentation is lacking and I try to make up for it in the short term by making myself available to help people as much as possible. Will do. If you could make issues for the stuff you are working on and put it on the github roadmap, or even just a text file with a big long list of "things to be done" (or link me to it if it already exists ), that would be helpful. Is this the best thread to post in? I feel like my comments belong more in "Development & Technical Discussion" |
|
|
|
Looks promising. It's clever to have to key split like that but I still do not figure what will happen if the server goes awol with the other half of my key. How can I send my bitcoins to another wallet?
Like nmat said, the suggested procedure is to request the server to send you a backup - ideally through some method that is outside of your computer, the most obvious being snail mail. But it's completely up to the server what they want to offer their users. For example the red keys could be on your mobile phone and the server only handles the messaging in between. The point of the talk is simply that a browser-based client can benefit from the split keys just like a desktop client can. And split keys in turn open up a whole world of possibilities. I'm excited about bitcoinjs. I am going to experiment with putting webcoin into phonegap. That gets rid of the problem brought up in the video of the server being compromised and distributing malicious js. The attacker would have to upload a modified app and then the target would have to update their phone to the compromised version. The split key idea is interesting. I really want a thin client for my phone. Your JS library and accompanying code will be very useful. |
|
|
|
So while abe was indexing all of the blocks, I came across http://bitcoinjs.org/. For the last few months I keep flip-flopping between node and python. As a webdeveloper, I pretty much have to use javascript, so node is very appealing to me. As much as I love python and the ideas of electrum, I think I am going to work on my phonegap thin-client using bitcoinjs instead of electrum as the server. I'm still going to run an electrum server, but it looks like my coding efforts will go elsewhere. block_tx 31386 31603 after just over 3 hours. My VM host was acting up for a bit and not giving the guest it's full CPU, but it seems to have sped up now. |
|
|
|
|
Show Posts
