Pages:
Author

Topic: Proof of Min - page 2. (Read 1803 times)

staff
Activity: 4284
Merit: 8808
August 14, 2014, 06:46:59 AM
#11
NTP isn't trustless. You trust your servers and if they lie to you, your time will be wrong.
full member
Activity: 126
Merit: 100
August 14, 2014, 03:49:45 AM
#10
Or maybe a random nonce is unnecessary! Because it will be impossible for the miners to know what exact transactions will be included in the block. And then the UTC timestamp itself will act as a nonce. And the UTC timestamp is fixed and cannot be altered since it must be included in the block. A miner can then pre-calculate blocks but only in a limited way since the stream of new incoming transactions is unpredictable.
full member
Activity: 126
Merit: 100
August 14, 2014, 03:29:58 AM
#9
... or a malicious entity can just recode the client to produce a timestamp and nonce combination which is already known to produce a very low hash value.

Another part I forgot to answer. The timestamp nonce is included in the block. So the miners can check if the nonce included is the same as the current START timestamp nonce from the distributed time server. The miners have to wait for the START nonce in real-time, since they don't know what the random value of the nonce will be. And if the miners try to generate their own nonce values, the other miners will immediately see that those values are different than the Start timestamp nonce from the distributed time server.
full member
Activity: 126
Merit: 100
August 14, 2014, 02:51:09 AM
#8
Who really needs such a quick transaction period?

I forgot to answer that. Here is a use case:

1. Person A buys a coffee at Starbucks.
2. A restless person B standing in line shouts "Hurry up, will ya?"
3. Person A pays with a two-second bitcoin transaction.
4. The cashier sees that the transaction was completed.
5. The next customer standing in line can be served.

 Cheesy
full member
Activity: 126
Merit: 100
August 14, 2014, 02:43:45 AM
#7
And send 10 gajigga bytes of potentially min traffic around the network.  Besides unless your "distributed timestamp server" is another POW blockchain (in which case nothing has been achieved) its not obvious how to construct that in a decentralized way.

Generally if you can assume the existence of such a construct no mining is needed at all. Mining exists basically to solve that problem.

So you mean such distributed time server would remove the need for mining entirely? The time server could be tricky to implement, but maybe doable!

NTP is perhaps something that could be used as a foundation for the distributed time server:


Are you saying that your whole proposal is building on "perhaps something"? Come back after you figure out how it might work.

A distributed time server with random nonce generation is probably tricky to develop. But it's the general idea I wanted to present. So that other people can figure out possible solutions or explain why it would be impossible.
legendary
Activity: 1792
Merit: 1111
August 14, 2014, 01:51:56 AM
#6
And send 10 gajigga bytes of potentially min traffic around the network.  Besides unless your "distributed timestamp server" is another POW blockchain (in which case nothing has been achieved) its not obvious how to construct that in a decentralized way.

Generally if you can assume the existence of such a construct no mining is needed at all. Mining exists basically to solve that problem.

So you mean such distributed time server would remove the need for mining entirely? The time server could be tricky to implement, but maybe doable!

NTP is perhaps something that could be used as a foundation for the distributed time server:


Are you saying that your whole proposal is building on "perhaps something"? Come back after you figure out how it might work.
full member
Activity: 126
Merit: 100
August 14, 2014, 01:25:56 AM
#5
Your idea is flawed.

1. How would a distributed time server generate a single, unique nonce per block? Either the nonce generator would have to be centralized, which is obviously not wanted in a decentralized currency, or a malicious entity can just recode the client to produce a timestamp and nonce combination which is already known to produce a very low hash value.

Here is an example of random nonce generation:

"(I'm aware that people on the forums are coming up with randomness protocols for proof-of-stake, proof-of-activity and the like which don't involve external true randomness like lotteries - they just hash the last hundred blocks' hashes together, or something like that. I don't think this is good enough. [For their application or for mine!] Someone producing the latest block, given the previous 99, can privately produce billions of cheap variations on it, by varying the order the transactions are listed etc, until they find, and publish, the one that "games" the randomness in their favour. However, if I'm wrong about this, and hashing the last hundred blocks is in fact fine, then good! We can drop the lottery rigmarole!" -- https://en.bitcoin.it/wiki/Proof_of_burn

Quote
2. In order to check which hash has the lowest value, the network would have to store every submitted hash until the block is found. If each miner could produce at least 1000 hashes per second and there were at least 100 miners currently hashing, then at least 1 million hashes with their accompanying block contents would have to be stored by each node that verifies the hashes every couple of seconds. That's a lot of memory, not to mention a lot of overhead in time to verify each hash in case any malicious entity submits multiple fraudulent hashes with low hash values. 1000 hashes per second is not even a lot.

Each miner would only submit one hash value (the lowest found during the time period).

Quote
3. 2 second transaction times will create an extremely bloated blockchain, not to mention a ton of orphaned blocks. Who really needs such a quick transaction period?

That could be a problem. I don't know the exact details about that.
full member
Activity: 126
Merit: 100
August 14, 2014, 01:20:16 AM
#4
And send 10 gajigga bytes of potentially min traffic around the network.  Besides unless your "distributed timestamp server" is another POW blockchain (in which case nothing has been achieved) its not obvious how to construct that in a decentralized way.

Generally if you can assume the existence of such a construct no mining is needed at all. Mining exists basically to solve that problem.

So you mean such distributed time server would remove the need for mining entirely? The time server could be tricky to implement, but maybe doable!

NTP is perhaps something that could be used as a foundation for the distributed time server:

"Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in use. NTP was originally designed by David L. Mills of the University of Delaware, who still develops and maintains it with a team of volunteers.

NTP is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC).[1]:3 It uses a modified version of Marzullo's algorithm to select accurate time servers and is designed to mitigate the effects of variable network latency." -- http://en.wikipedia.org/wiki/Network_Time_Protocol
sr. member
Activity: 399
Merit: 257
August 14, 2014, 01:18:46 AM
#3
Your idea is flawed.

1. How would a distributed time server generate a single, unique nonce per block? Either the nonce generator would have to be centralized, which is obviously not wanted in a decentralized currency, or a malicious entity can just recode the client to produce a timestamp and nonce combination which is already known to produce a very low hash value.

2. In order to check which hash has the lowest value, the network would have to store every submitted hash until the block is found. If each miner could produce at least 1000 hashes per second and there were at least 100 miners currently hashing, then at least 1 million hashes with their accompanying block contents would have to be stored by each node that verifies the hashes every couple of seconds. That's a lot of memory, not to mention a lot of overhead in time to verify each hash in case any malicious entity submits multiple fraudulent hashes with low hash values. 1000 hashes per second is not even a lot.

3. 2 second transaction times will create an extremely bloated blockchain, not to mention a ton of orphaned blocks. Who really needs such a quick transaction period?
staff
Activity: 4284
Merit: 8808
August 14, 2014, 01:08:57 AM
#2
And send 10 gajigga bytes of potentially min traffic around the network.  Besides unless your "distributed timestamp server" is another POW blockchain (in which case nothing has been achieved) its not obvious how to construct that in a decentralized way.

Generally if you can assume the existence of such a construct no mining is needed at all. Mining exists basically to solve that problem.
full member
Activity: 126
Merit: 100
August 14, 2014, 12:24:46 AM
#1
Here is a system for fast transaction times called Proof of Min (PoM):

A distributed time server generates UTC timestamps every second with low network latency. Each timestamp includes a random nonce that is unknown until it is generated by the time server.

The timestamps alternate with the types START and STOP. When the miners receive a START timestamp they start searching for blocks with as low hash value as possible. Each block includes the START nonce. When the miners receive a STOP timestamp they check which of the submitted blocks has the lowest (min) hash value and include it in the block chain.

EDIT: Each miner submits one block (with the lowest hash value found during the time period) to the network of miners. The block must be sent before the next STOP timestamp, early enough to be registered by the other miners.

This will give transaction times of around 2 seconds.
Pages:
Jump to: