Show Posts
|
Pages: [1] 2 »
|
Hopefully devs get back on track. Shield has some good features that make it superior to other cryptos.
|
|
|
Is this built using Zcash? or what privacy features does this have. I am looking for privacy coins to invest in.
|
|
|
What privacy features does this coin have? and does it have masternodes?
|
|
|
Idea is nice but what is this? Is it an ICO, Airdrop...mineable only?
|
|
|
Any new updates coming to Litecoin? What about adding a privacy feature?
|
|
|
Is it like the Brave browser? what are the advantages over Brave browser?
|
|
|
Nashville Predators 5 @ 2 New York Rangers
|
|
|
New England Patriots 33 @ 23 Atlanta Falcons
|
|
|
I should also note that I'm kind of an architecture snob. I don't like hacks. I like clean, well designed code, with lots of separation between layers, and lots of comments. This is mostly just a for-fun project for me, so I will probably have strong opinions about how something should be designed. It's practice.
|
|
|
Sweet. Any places you feel the code needs immediate attention? I'll probably screw around with it this weekend.
Well, BFI_INT stuff needs to be added. That's pretty crappy to do though. Most of the outstanding stuff I need to do requires a bit of rearch. I want to add support for running miner plugins out of process of the main program. Once that is in, the processes can be started and stopped dynamically in the Console session, so they have GPU access. I need more events flowing from the miner processes up to the main program. They already expose Resources, which represent something like a CPU, or a GPU, but those Resources can be a bit more descriptive. Hash count tracking per-resource would be nice. Then, when the main program is getting events from all of the stuff it's running, the console UI can be updated a bit (maybe using curses stuff) to show exactly what's happening. What GPUs are running. What pools are running. What GPUs are working on work from what pool, etc. I'd like a miner plugin factory to be able to, with a resource, also advertise possible run-modes of the miner. Such as work group size, vector modes, etc. This way, instead of the user having to specify what options he wants the program to use, it just tries them all during the test phase, and picks the fastest. Pool configuration stored in some other structure than System.Configuration would be nice. Or maybe System.Configuration is fine, but it needs to be configurable at runtime. You need to be able to alter the pools at runtime... for a future WPF UI.
|
|
|
Ok, this is very cool. I was looking for someone who had done this. If you need help with this, give me a hollar. There is a reason I may be an ideal coding partner on this, which I will share over PM if you're interested. You beat me to it. I was still on the OpenCL .NET wrapper step. That said, I've only been looking into Bitcoin for 9 days Next step: .NET pushpool. That may be my next "side" project... Well there's work to be done on it, so just do it.
|
|
|
I've never even noticed this! Assumed you were talking about the SHA256 one. I'm still going to assume it's faster for all the same reasons minus the P/Invoke.
|
|
|
What speed are you seeing on the completly managed SHA256 hasher you've made compared to the one built into the .net libary?
Don't know. Never tried the .Net one. I assume much faster. The .Net one's interface requires you to submit a byte[] of the data, which it no doubt has to split up internally into 64 byte blocks, and add the padding to. Additionally, when output, it probably reverses the endian. And thus it has to reverse it again when doing the second hash. And the second hash no doubt has to be copied, and padded, too. Also, I suspect that it probably uses CryptoAPI, so results in a P/Invoke.
|
|
|
The LP spec doesn't say "the LP request is not a JSON RPC request" explicitly. If it did, then, yes, I could get away with doing GET. Receiving a JSON RPC response is questionable at best in the case that this is true (although normal JSON over HTTP obviously is GETtable).
I don't particularly like the idea of mixing JSON RPC and non JSON RPC in the same protocol. If the LP spec says that you don't need to send a JSON RPC request, then the LP spec is wrong.
I agree. It's not much of a spec. It's more like, 5 half-assed written paragraphs. But that's fine. We do with it what we can. Perhaps the problem is you shouldn't consider LP as JSON-RPC. Maybe it's not. After all, if it was, it would not specifically mention GET. It's just a hack. I don't see any other way to interpret it. It's a GET request whose response is a JSON-RPC method response packet, completely outside of the normal JSON-RPC flow. It should also be noted that no matter what you POST to it, it works. You can post completely arbitrary data, and it will still respond with a JSON-RPC response. Or you can post nothing. It is clearly not JSON-RPC.
|
|
|
From deepbit: Miner starts a request to long polling URL with GET method and same basic authorization as on main connection.
It does not specify whether there is a body. I should note, that I do not use a body, and it works fine, with every pool I've seen. If it does expect a body, it is a contradictory spec, as you said.
|
|
|
Okay. I now support multiple pools. The format of the .config file has changed. <bitmaker.miner> <pools> <add url=" http://user:pass@host:8332/" /> <add url=" http://user:pass@host:8332/" /> <add url=" http://user:pass@host:8332/" /> </pools> </bitmaker.miner> Each time a thread desires work, it starts at the top and works it's way down. So, the pool at the top, if it's working, is currently always used. If it fails, the next one is tried. Work gets submitted back to the correct pool. Thinking of implementing some sort of priority classing and load balancing to that. Maybe poolGroup or something.
|
|
|
ANY client that EVER uses GET for JSON RPC is wrong. Read the HTTP spec, GETs should never have message bodies. DiabloMiner follows the HTTP specification and uses POST for all requests.
Can you clarify this a bit? My understanding is that a LP URL does not have a body, and thus using GET is just fine.
|
|
|
It's decent. It's a proper wrapping of OpenCL. There's a small annoyance with a memory leak of ComputeEvent's being generated even though you pass null as a event list for most calls. That's easy enough to solve by passing a list to put them in and disposing of them immediately though. The only thing really wrongn with it is a complete lack of documentation as far as I can see. That's fine though, since it's nothing but a loose wrapper over OpenCL itself.
|
|
|
You don't really yet. It loads and attempts to run every plugin it finds. If the .Gpu assembly is in the same folder as the .exe, it's tested, and runs.
If the .Sse assembly is there, it's tested and runs. Same with .Managed.
Step #1 for me was getting an actual working miner. Next steps are making the thing configurable, usable, etc. I had previously decorated the code with Console.WRiteLIne's for each plugin, so you could see what the hell was going on, but kind of removed them all.
|
|
|
|