9706
Marketplace / [SOLD] 2000 PTS at .0026 BTC [COMPLETED]
« on: November 06, 2013, 06:39:35 pm »
Post in this thread if you are interested.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Just send 140 protoshares over to my main wallet fee 0.01 - is that enough? do you even need a fee at this state? or did I mess up and have to wait days for tx? :S
Sent 140 Shares with a 0.01 Fee - took around 30mins
Send 49 Shares with 0 Fee - instant
is that right?
Okay if I understand correctly your proposed PoW algorithm, we are generating pseudo-random values that can range over the address space of the memory size we target until we generate a duplicate (or triplicate). The Birthday math tells us that we will find a solution with 50% probability before visiting less than roughly 10% of the addresses, or 99% before visiting less than roughly 20% of the addresses. Thus this is a way to require large memory without actually writing to every memory address, i.e. a sparse memory access algorithm. Btw, I also considered this sort of algorithm before and dumped it.
Assuming the generation of the pseudo-random values can be accelerated by parallelism, i.e. that the algorithm is main memory latency bound, then the GPU is going to be much faster, because the GPU masks memory latency by employing 1000s of threads, i.e. we can test 1000s of pseudo-random values in parallel. This was the key myopia that caused Litecoin to fail at stopping GPUs from outperforming CPUs, although it did improve the difference relative to Bitcoin's PoW.
I don't see how the use of a hash table really changes the outcome significantly, as it will only serialize perhaps every 10 buckets and we assume the pseudo-random values are uniformly distributed over the entire address space. Collisions with a 1000 threads are going to be rare.
I have revealed my key insight into PoW. If you weren't aware of this and I am correct, I hope you tip me consumerately.
Ok... a few corrections for you to consider. The address space of the birthdays is 50 bits. The TARGET_MEMORY is the number of birthdays that must be stored to have a 90+% probability of finding 1 collision once you have filled TARGET_MEMORY. As a result, this isn't sparse memory access unless you are operating on some MULTIPLE of the TARGET_MEMORY and that multiple would have to be very high (scaling with the number of GPU threads) if you want to avoid threads stomping on each other with high probability.
Your GPU algorithm is still O(C * N^2) where C is some constant factor improvement.
CPU algorithm is O( C * N )
While the GPU can hide latency it cannot change bandwidth and your bandwidth usage is still N^2.
Okay if I understand correctly your proposed PoW algorithm, we are generating pseudo-random values that can range over the address space of the memory size we target until we generate a duplicate (or triplicate). The Birthday math tells us that we will find a solution with 50% probability before visiting less than roughly 10% of the addresses, or 99% before visiting less than roughly 20% of the addresses. Thus this is a way to require large memory without actually writing to every memory address, i.e. a sparse memory access algorithm. Btw, I also considered this sort of algorithm before and dumped it.
Assuming the generation of the pseudo-random values can be accelerated by parallelism, i.e. that the algorithm is main memory latency bound, then the GPU is going to be much faster, because the GPU masks memory latency by employing 1000s of threads, i.e. we can test 1000s of pseudo-random values in parallel. This was the key myopia that caused Litecoin to fail at stopping GPUs from outperforming CPUs, although it did improve the difference relative to Bitcoin's PoW.
I don't see how the use of a hash table really changes the outcome significantly, as it will only serialize perhaps every 10 buckets and we assume the pseudo-random values are uniformly distributed over the entire address space. Collisions with a 1000 threads are going to be rare.
I have revealed my key insight into PoW. If you weren't aware of this and I am correct, I hope you tip me consumerately.
Can you provide a script to check the mature balance and send them automatically? I don't have time to check and send them manually.
If I have a script, I will rent a few. Or an alternative way is to store the private key out somewhere after each block mined.
I had been mining on my macbook air for a while before this issue happened. Now the client tells that:
Error loading block database. Do you want to rebuild the block database now?
I click OK. It gives me:
ProtoShares-Qt quit unexpectedly. Click Reopen to open the application again. Click Report to see more detailed information and send a report to Apple.
I am trying to locate the blockchain directory on OSX, but it's not there where the bitcoin blockchain would be. I am thinking just delete the blockchain, if I can find it.
Thanks.
For example: Suppose momentum as specked requires about 1 GB of RAM for maximum performance and produces hashes at 1hz. If you design an algorithm that only requires 1 MB of RAM and can find hashes at .001 hz then you win because you will have proven that computational complexity is linear with RAM use rather than non-linear like I believe the problem calls for.
Best of luck to you all!
I believe there is a weakness where GPUs can run much faster, but it doesn't requiring lowering the memory. If I explain it to you and am correct, do I qualify for at least part of the bounty?
It is possible I am incorrect or have misunderstood some aspect of the algorithm, so let's not jump to conclusions yet.
Would you please clarify exactly what TARGET_RAM_USE is? Is it the total memory required to store the hashtable of all nonce results or some smaller value?
Should we use your example from http://bitsharestalk.org/index.php?topic=21.msg26#msg26 to empirically confirm? Also could you release FreeTrade's current implementation or standalone subset you mentioned there for testing?
Thanks,
Nathaniel
A new client with different difficulty target adjusting time may cause the blockchain diverged.
Sent from my iPhone using Tapatalk