Time-limited Proof-of-work

#1

Academically, what stops someone from creating a proof-of-work based cryptocurrency that utilizes a variation of Peercoin’s proof-of-stake timestamp limited hashing algorithm? That is to say, to secure the network, each node (wallet client or daemon) is able to attempt to solve a block, but it can only do so once per second?

By design, Peercoin’s proof-of-stake scheme is ASIC-resistant, so does it logically follow that it could be applied to proof-of-work with the same benefits? If it could be, does it not also follow that an egalitarian method to mine coins (and to protect the network) could be developed with a very small energy footprint?

#2

The problem is if you don’t include something that only you own then everyone will produce the same hash. So everyone will find a block at the same time. The winner will be the one with the best network.

If you include some randomness, then you’re back to standard proof of work where you can always add more power to try more random data.

#3

[quote=“sigmike, post:2, topic:1769”]The problem is if you don’t include something that only you own then everyone will produce the same hash. So everyone will find a block at the same time. The winner will be the one with the best network.

If you include some randomness, then you’re back to standard proof of work where you can always add more power to try more random data.[/quote]

Is there a mechanical reason that the randomness in the system cannot be provided by a unique seed/attribute of each client?

I’m not quite sure I understand why the same hash would be generated for all of the clients. If there are 100 nodes in the network, each trying to solve the current block at one attempt per second, how is this different than 100 nodes on the BTC network, each hashing at 100 GH/s?

I’m very interested in continuing my study of the underlying mechanics of how cryptocurrencies work (I’ve been slowly working my way through Ken Shirriff’s articles on how Bitcoin transactions work), so any insight I can pick up here is valuable.

Thank you in advance!

#4

There are many things that are somewhat random and unique on every client. But whatever you choose it can always be faked. You will always be able to write a client that generates hashes with a fake unique attribute.
Take the MAC address of your network card for example, or the serial number of your OS. I can write a client that generates thousands of these items make it generate thousands of hashes per second.
That’s the beauty of PoS. You have to use something very unique and that only you can prove you own: your coins.

If you include randomness then all nodes will generate a different hash but you’re back to PoW.
If you don’t include randomness then everyone generates the same hash. That’s how hashing works.

#5

I may not be all that helpful regarding this thread in the overall scheme of what you’re asking.

However whenever I see the words ASIC-resistant, I shudder with disappointment.

If people deploy a massive number of ASIC based hardware to secure cryptocurrency, because it is cheap, and plentiful, then why not use those resources to the benefit of cryptocurrency in general?

A block errupter at 335 Mh/s is $15 - $40 USD on Amazon. Yet a lot of coins pride themselves on being ASIC-resistant.

I’ve never understood that. There is “luck” involved with using your ASIC hardware to successfully mine a block. If all these ASIC chips are all over the place, successfully mining Bitcoin and Peercoin with less electricity than a standard GPU card, why is it so important to be “ASIC-resistant” ?

I think cryptocurrency and related coins should be “ASIC friendly”, where anyone can run an ASIC miner, have the same luck chances at finding a block, with low electricity consumption.

Instead, for some weird reason, people think GPU or CPU difficult mining activities is a good thing. It’s actually quite terrible. All it causes is botnet owners to infect massive amounts of victim computers with malware to help them create a mining botnet for their own purposes.

ASIC chips, by default, aren’t inherent laptops and desktop machines. Why aren’t we embracing ASIC chipsets and using that concept to our benefit?

ASIC-resistant is quite a misnomer that needs to be addressed, sooner than later.

#6

I agree with what you wrote, ppcman. In this context, my intent was not to vilify ASICs, but instead to mean that no one was able to disproportionally apply technical resources. One attempt per second, per client, regardless of the RAM, processor clockspeed, GPU, or hard drive I/O. Someone with a Raspberry Pi has the same (technical) ability to mint blocks that someone running an AWS c3.8xlarge high-compute instance has.

It was a poor choice of phrasing, on my part, for “technologically fair.”

#7

(Sorry for my previous ASIC-resistant rant. I was over eager to finally expel my thoughts on that concept)

Academically, nothing every stops anyone from creating any type of cryptocurrency with certain features, and it is a good question posed. As always though, keep in mind, there is nothing to stop Peercoin having those some features with an update by Sunny once Peercoin has wider acceptance.

I fully believe though, that this whole concept of “earning interest” or “mining or minting coins” is something that will quickly become unimportant in the long term scheme of things. Today we have those benefits, and that is why miners mine, or why proof-of-stake minters mint.

But the whole concept of bittorrent succeeds based on the fact that your client is always contributing to the network’s health while you wait for your download.

A wallet and transaction should be similar. We shouldn’t have to actively be in “mining mode” or "minting mode’ for the network to survive and do well. We do these things today, because cryptocurrency isn’t common place yet. (Just ask your neighbor, and you’ll see my statement is true, we’re years before digital currency is part of every one’s daily life)

Once cryptocurrency is common place, the protocol can be designed to take advantage of that fact.

I agree with your time limited hashing algorithm concept, “as a concept”. Keeping every one on the same “per second” UTC rhythm would be quite a feat.

Right now we have time adjustments in the Bitcoin protocol that work, but are annoying to watch in debug.log when they show up. It proves how out of sync the world is… Synchronized time is quite a challenge. Having every one synchronized every single second globally, would be an incredible challenge.