Its an interesting idea. Instead of an arbitrary proof of work scheme, why not work on solving a problem that has some utility. as an example (i know its not a good one because this particular example wouldn't work but its just to convey a point) we could be attempting to solve pi. You could prove that you worked hard by discovering a previously undiscovered digit of pi (hence the proof of work) while adding something of value to the scientific community at the same time.
You really can't do that with something like protein folding simulations (I would know, I've worked in the field for three years...). In fact, most scientific problems involve calculations applied to stochastic problems where they don't necessarily know what the results will be. The only way I can think of is to just use a ripple like system where whatever at home gives you credits based upon your solutions being provided to them. But it's not necessarily a bad answer to this problem, it's better than folding and getting nothing but points on a leaderboard. If opencoin just released their source code you could directly port it and then use it to make a network like ripple for your coins -- but they haven't. |
|
|
|
Litecoin is a scheme to water down the value of Bitcoin by producing a 400million coins and then taking away the miners. Litecoin is an inferior coin because theres over 400 million.
Litecoin converges to a total of 84 million coins. Maybe you're thinking of NVC/PPC, where coin generation is fairly random because it's based on network hash rate. |
|
|
|
|
Lots of people have contacted me, I contacted one back, haven't heard from him, so I'll be contacting another one of you soon
|
|
|
|
Hey, I need something for you to properly implement this in GUIminer, which is to allow a flag that updates the hash rate piped to the console at a given rate, eg 1 line containing hash rate and hashes per second. Then it should be ready to go.
Aggregated over all GPUs? Isn't the term hash rate synonymous to hashes per second? I will see what I can do. Okay, so this is what I exactly need if you have time and the inclination to help: - argument flag that enables a "quiet" mode - "quiet" mode entails starting the miner, then reporting the hash rate/hashes every second as the program normally does - accepted/rejected messages are reported after a share is submitted - everything is passed directly to stdout rather than using applog (since it mangles the output for python). not sure if it matters what function (cout or printf) This is almost exactly like -T mode for cgminer. The weird thing is that the miner looks fine in console but subprocess can't see any of the data the program is outputting -- like it doesn't use stdout/stderr or something. If it still fails to output correctly I'll try to write a hook program in C++/python and play around with it... |
|
|
|
I will be the first to say that I'm pretty terrible at math How are people going to trust you if you don't know about math. Whoever Satoshi was he was a genius in math and cryptography. I "know about math" and I got an A (barely) in Calculus I/II and computer algorithm analysis, I'm just not very talented when it comes to numbers. Sorry guys, this cudaminer update to guiminer-scrypt is proving a nightmare right now.. I'm going to work. |
|
|
|
Code for cudaminer integration is 100% complete but python doesn't want to recognize the console output from the program (  ), so I guess I'll have to work on it tomorrow. It sucks because it's done for the most part, for some reason it just doesn't want to work. import os, subprocess, sys
cmd = "\"C:\Python27\poclbm\cudaminer\cudaminer.exe\" -o http://ltc-pooldirect-a.kattare.com:9332/ -O user:pass -d 0 -i 0 -l auto -C 0 -m 1"
# cmd = "dir"
print cmd
p = subprocess.Popen(cmd,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
universal_newlines=True,
creationflags=0x08000000,
shell=True)
while True:
inline = p.stdout.readline()
if not inline:
break
sys.stdout.write(inline)
sys.stdout.flush() Uncomment dir and dir command runs and outputs just fine. Run cudaminer instance inside python and nothing shows up, despite cudaminer working fine outputting to console using the command in the command prompt. No clue. |
|
|
|
Something really weird goes on when trying to dump stdout and stderr using subprocess with python... Having a nightmare of a time with it, basically nothing comes through stdout/strerr until I close the process, in which case a million or so "\n"s show up. Argh. Going to bed soon, but this is driving me nuts. edit: It looks like applog's function is writing to something that python doesn't recognize as stderr or stdout (which is weird because cgminer/reaper are fine...) at the level of the console For instance, if I run this code: import os, subprocess, sys
cmd = "\"C:\Python27\poclbm\cudaminer\cudaminer.exe\" -o http://ltc-pooldirect-a.kattare.com:9332/ -O user:pass -d 0 -i 0 -l auto -C 0 -m 1"
# cmd = "dir"
print cmd
p = subprocess.Popen(cmd,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
universal_newlines=True,
creationflags=0x08000000,
shell=True)
while True:
inline = p.stdout.readline()
if not inline:
break
sys.stdout.write(inline)
sys.stdout.flush() Nothing happens, although an instance of cudaminer is indeed spawned. However, if I uncomment the cmd = "dir" line, python outputs the stdout response of dir just as expected! In the meantime, if you run in windows and use "> output.log 2> output.err.log" you get a normal stdout and stderr log. No clue what's going on! |
|
|
|
Hey, I need something for you to properly implement this in GUIminer, which is to allow a flag that updates the hash rate piped to the console at a given rate, eg 1 line containing hash rate and hashes per second. Then it should be ready to go.
Aggregated over all GPUs? Isn't the term hash rate synonymous to hashes per second? I will see what I can do. Yeah, but cgminer and reaper send an update as to what the current average khash/s is every second (reaper by default and cgminer if you set the interval to 1 sec). It doesn't matter if it's across all GPUs or one, as guiminer uses separate instances for each video card. I'm not sure if it does already, but you may also want to have the program save autotune settings after it calculates them as well, to reduce the amount of time it takes upon running it again. Stale rates are also high on my GTX 460 (7%) with autotune, not sure why. Thanks! |
|
|
|
|
Hey, I need something for you to properly implement this in GUIminer, which is to allow a flag that updates the hash rate piped to the console at a given rate, eg 1 line containing hash rate and hashes per second. Then it should be ready to go.
|
|
|
|
Question: Will this still use ECDSA for signing? It'd be cool to use something like NTRU ( http://en.wikipedia.org/wiki/NTRU) so this isn't vulnerable to quantum computers. It could be, but the problem is the size of NTRU private/public keys and then the message transmitted. Ideally for NTRU n=503, p=256, q=3 because of the likelihood of lattice attacks at lower values; size of NTRU private and public keys are 2(n)log2(p) and (n)log2(q) bits respectively. Thus we're looking at 1595 bits for private keys and 4024 bits for public keys. With ECDSA, we have only 256-bit private keys and 528-bits for public keys. The message expansions are also quite a bit larger I think, which may contribute to block chain bloating. Note that (as far as I'm aware) application of Shore's algorithm to ECDSA as implemented in Bitcoin also only reduces the theoretical search space for private keys from 2^128 to 2^64, so the even with widespread adoption of quantum computers it may be difficult to attack. With NTRU n=503, p=256, q=3 you're looking at a more secure blockchain in comparison to ECDSA, though (authors quote message security is 2^170). |
|
|
|
Well what it comes across is, is simply a get rich quick scheme of refusing to simply just actually let the damn thing get developed.
It seems more like "sorry we will not allow development to proceed unless we get paid" than "we are doing everything possible to ensure this free open source project gets developed as fast and well as possible but all the people contributing pulls to the git repo are stuck on some particular item that is beyond them so we will have to pay a professional to do that part for them".
Just specify the damn thing so it can get started. There seems to maybe even be some "oh we don't want to even be clear what the thing is unless we get paid" too maybe?
-MarkM-
The new specifications will be up within the next couple of weeks, I'm just musing over the potential costs of the project. Rest assured I don't need anyone's money, and I'm perfectly happy to spend hours sitting in front of a whiteboard drawing things out for what I hope will be the future benefit of the community for free. This is something I do in my free time. I hope that everyone understands and will try to be patient. |
|
|
|
Not needed at all, instead just first run an alpha net of it, let anyone interested terst it to destruction, then when ready to go beta start over with a beta, then once all the kinks are out of it start over with the real launch.
Look how many people want to help for free on getting PPCoin right, the only thing stopping oodles of free hours being put in on it is the lack of an actual whitepaper detailing what the heck it is actually supposed to be.
-MarkM-
I'd rather professionals do the audit -- the early versions of CryptoCat are a good example of how badly community guided free open source software for cryptographic technology can fail. At the end of the day I'd like to try to raise $40-50k and pay all the coders and auditors appropriately. PPC is also a bad example. The first major vulnerability was detected by Jutarul, who ended up not being a malevolent attacker. As the chain increases its market share, we may not end up being so lucky in the future. I do not want this to be centralized chain controlled by my checkpointing, because that's counter to everything a decentralized currency stands for. |
|
|
|
|
Netcoin (I guess I'll adopt that now) won't be that easy. If it was a matter of another Feathercoin or whatever, then yes, you can change a few constants in the code and be done with it. But a lot of what I'm planning to change will require more than minor overhauls of the code. I would guess you're looking at 60-100 hours of coding among developers (minimum) after testing of individual functions is done thoroughly, then you need testnet security audits. The security audits would be a critical component and would likely run into the $10,000 - $20,000 USD zone. But, it's more important that the code works as intended out of the box, as this is a proposed financial system.
|
|
|
|
|
The only thing that surprises me is that LukeJr has time to sit around arguing on a Wiki talk page instead of actively developing Bitcoin.
|
|
|
|
I am getting some memory_management BSODs sometimes when using your miner, I have two reaper miners, both set to automatically start when I run it. I'm not sure if this is reaper's fault or the guiminer's though.
I have had two things causing BSODs while mining with reaper/cgminer: 1) Memory on motherboard is bad. 2) GPU is bad or seated improperly in the board/riser. |
|
|
|
|
Hi guys,
Hopefully next release of GUIMiner is out tonight and I can start getting back to everyone's replies here in the thread. I can't promise long replies to everything, but I'll give my opinion and let you know what I think.
|
|
|
|
|
It's commented, just vaguely eg
"This fragment of code does this"
|
|
|
|
You need to increase the output size of the hash to above 64 bits to get any reasonable amount of security... even SHA1 has a 160 bit output. Then you introduce the very real possibility of NMC-style chain bloat, as the input for these parts of the tx on the blockchain would have to be arbitrary. |
|
|
|
You can use a consensus network via stake to do ledger verification, too. I think PoS makes transaction pruning impossible. How would you suppose to check if miner of block N in the past really held claimed amount of stake at time of block signing if you forgot how account balances looked at that time? Make a checkbox in the client to enable full or pruned blockchain download. Pruned blockchain can just download the block from a bunch of full nodes in the event of a dispute. The danger of a sybil attack exists, but I don't think it's great. Yes, it would be a good idea to include the block height and also the depth in the block in which the last tx appears. I think block height is sufficient for account ledger. I'm following from Actually minimum ledger entry is
(Address, amount, version)
Version is needed because coins are indistinguishable and without version a transaction to send first half of balance to some address would look exactly same as transaction to send other half of coins to this address. Simply receiver of first transaction could rebroadcast same, already signed transaction, in subsequent block and receive rest of coins. Version needs to be increased after every withdraw from address in order to defend from this kind of fraud. I think version can simply be block number in which last withdrawal was included. I'm not sure I even follow this logic, though. If the ledger contains every address and every amount of coins at every address, whenever a block is received you can just adjust the ledger accordingly. For instance, block n: send 50 coins to address 1 from address 2 block n+m: send 50 coins to address 1 from address 3 Client sees both tx at different times, adds 50 coins each time to adjust the ledger, hashes the ledger and checks it against the one in the next block found. Address 1 contains 100 coins, while both address 2 and address 3 contain 50 less coins. That the amount is duplicated is of no consequence as long as the quantities are adjusted per block. If you want to include stake, you just input the block height and make separate amounts for each input. Or, you can simply ignore this and just download the block from one of the full blockchain clients from which the stake is claimed to arise. All the block hashes are easily able to be stored by anyone, so verification of any single block in the blockchain history is very simple. Try to not overthink this. I believe including hash of state of all known accounts and its balances in block headers is sufficient to keep level of security similar to bitcoin.
Anyway new coin with finite blockhain would be a winner, because we could include one simple feature which would bring users to it: attaching custom message to a payment. Bitcoin cannot do this because it would bloat blockchain to unmanageable size, but it shouldn't be a problem when you can forget transactions and just keep balance sheet. You can just sign a message from the address you send it from... |
|
|
|
|
Show Posts
