What exactly does a perfect Bitcoin upgrade look like? Obviously some form of Anonymizing tech would be required, something to help speed up transactions and yet another upgrade to help spread out miners in a more decentralized fashion...
You may want to read up on MimbleWimble :-) http://mimblewimble.cash/
|
|
|
don't think anyone has any use for sha256 hashes of random data.
People do have a use for (cost/speed/energy-efficient) improved random-access-memory technology however, so a proof of work that makes random memory access, rather than hash computation, the bottleneck, will provide the right incentives for that...
|
|
|
Hi everybody, What i really don't like about bitcoin is the waste of computing power (= waste of resources) it needs to secure the network, and how things would get worse the more bitcoin becomes successful.
Because of this I was wandering which are, actually, alternative mining alghoritms that you are aware of, and possibly their pros/cons. I'd mantain such list in this OP and maybe group them up in a website if it could be useful, and discuss about mining alghoritms here to maybe come out with a new greener mining alghoritm or best block generation approach
If a post like this already exists (or website links) then please point me to it thanks
There is http://cpucoinlist.com/cryptocurrency-algorithms/for supposedly CPU-friendly proof-of-work schemes, but I believe it's no longer maintained and somewhat outdated.
|
|
|
As you can see, this system would preserve most of the current Proof Of Work characteristics of bitcoin mining but with a twist that allow the mining pools to put their system to rest for a significant period of time, thus saving energy and money. I've chosen the duration of the two phases in an arbitrary manner, so that, for every day of competition we'd 10 have days of minimal energy consumption.
While I can't see any major drawbacks to this system, I know how tricky game theory can be, so I'd love to hear your feedback on the idea.
Except that if you reduce all miner's energy costs by 90%, they will all use their vastly increased profits to buy many times more hashpower to maintain their share of the pie. You end up with 10x more hashpower sitting idle 90% of the time. In the end, you'll always have: cost of total energy spent on mining = block reward + fees ...
|
|
|
By then, the slow start period would have ended
It already did...
|
|
|
ASICs are good at number crunching, not number fetching DRAM is quite fetching :-)
|
|
|
On a more serious note: if you state the performance is now at 80% of theoretical maximum, we're basically there, right? ETH miners also peak at about 80-85% of the theoretical maximum. Does the same rule apply here?
I still have some work to do before I write my own miner from scratch. I like to *really* understand the problem before I start writing code, and there's still some parts of the GCN architecture that I'm figuring out. Hi, nerdralph! Would you be interested in going after my Cuckoo Cycle bounties? https://github.com/tromp/cuckoo
|
|
|
I've only spent about $1200 so far, and the $5000 is (mostly) backed by people who contributed to the Cuckoo Cycle Bounty Fund. It's far from certain that it will all be spent. Wouldn't it better to invest that $5000 in something with a future that can appreciate in value?
Most of the $5000 is held in BTC, and should appreciate just fine. Or do you see uses for that outside of blockchains?
As https://en.wikipedia.org/wiki/Proof-of-work_system shows, a proof-of-work may serve well for preventing spam and denial-of-service attacks. I went down that rabbit hole with you and I concluded there can never be a stable CPU proof-of-work.
IMO Cuckoo Cycle has the best odds of being an unprofitable-for-everybody proof-of-work.
|
|
|
Cuckoo Cycle is an instantly verifiable memory bound Proof-of-Work, whose run time is dominated by memory latency. I invite anyone to try claim one of the following bounties for performance doubling of my C++/CUDA solvers: CPU $2000 TMTO $2000 GPU $1000 or half the above bounties for a sqrt(2) performance improvement. Details at https://github.com/tromp/cuckooHappy bounty hunting...
|
|
|
Cuckoo Cycle is an instantly verifiable memory bound Proof-of-Work, whose runtime is dominated by memory latency. I invite anyone to try claim one of the following bounties for performance doubling: CPU $2000 TMTO $2000 GPU $1000 or half the above bounties for a sqrt(2) performance improvement. Details at https://github.com/tromp/cuckooHappy bounty hunting.
|
|
|
It's called the Founder's Reward...
|
|
|
CPU solving us highly memory and clock frequency bound and doesn't scale with cores well at all.
It scales reasonably well, althouh obviously sublinearly. 1x dev1 = 6.2 Sol/s 8x dev1 = 25.6 Sol/s on a 4Ghz i7. So more than a 4x increase from using 8 instances.
|
|
|
Even so, QCs cannot do preimage attacks on hashes, they can only brute force them faster. For mining, that just means that the difficulty will increase and blocks will stay the same. For addresses, that means that they still cannot find the associated public key because they still can't find the preimage.
It means that the PoW will change from being practically optimization free, as currently the case with near-optimal ASICs, to becoming extremely optimization prone, with huge advantages available only to the most advanced and well-funded organizations (like your favorite 3-letter agency). That is, mining power will go from fairly decentralized to absolutely centralized. A post-quantum bitcoin will need to move away from Hashcash to some asymmetric PoW.
|
|
|
also why this coin is not known?
Maybe because it's not the least bit decentralized?!
|
|
|
I'm guessing that with the sprint towards October 28th you don't have a whole lot of bandwidth to think hard about this, but if you do come across a reason why waiting until the end to prune duplicates doesn't work, or conclude that it does, a quick post here would be much appreciated.
Waiting until the end does in fact work. Maybe when @tromp becomes a ZEC-billionaire next month he'll publish one I have no plans to mine ZEC myself:-(
|
|
|
Hello folks, this thread appears to be the place with the highest concentration of zECQuihash optimization gurus. May I trouble you with a stupid question?
I'm trying to correlate that with the zcashd implementation, since it's the only available working cross-checker (too bad it is written for speed instead of readability). The only part that has me confused is the need to eliminate entries whose index sets contain duplicate/repeated entries after EVERY one of the k collision steps. There is no mention of this in the algorithm given in the Equihash paper.
I understand why these can't be part of the final solution (the X_i's must use distinct i's). But why not wait until the end to drop these superfluous solutions? Why check for duplicates k times? I did some quick back-of-the-envelope calculations and I'm having a hard time believing that leaving these entries in the table would significantly increase memory consumption. If you had a duplicate X_a in the second level of the collision, it would have to be a result of (X_a*X_b) colliding with (X_a*X_c) on the first 40 bits (where X_a collides with each of X_b and X_c on the first 20 bits). If this is true then
((X_a*X_b)*(X_a*X_c)) = 00000000000000000000 00000000000000000000
and therefore
(X_a*X_a*X_b*X_c) = 00000000000000000000 00000000000000000000
so
(X_b*X_c) = 00000000000000000000 00000000000000000000
and moreover
(X_a*X_b) = 00000000000000000000 ....................
(X_a*X_c) = 00000000000000000000 ....................
In general it seems like repeated indices arise in the Equihash-constrained variant of Wagners algorithm as a result of an "overcollision" -- when two rows of the table collide not just on the current column but the next one as well. When this happens the members of the overcollided set will generate one suprious entry in the next round for every entry they collide with in the current round. It seems like that would happen on average twice per column. Is that really enough to bloat the memory usage in a noticable way for k=10? Surely for something like k=100 we'd be talking about serious combinatorial explosion, but for k=10 there just aren't that many steps compared to the size of the table.
Sorry if I overlooked it, but where is the stupid question? All I see are some very astute observations. Welcome to club Guru!
|
|
|
|