Bitcoin Forum

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.

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.

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?

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

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


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


That could be a problem. I don't know the exact details about that.

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.

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.

 :D

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.

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.

NTP isn't trustless. You trust your servers and if they lie to you, your time will be wrong.

Hmm... Not good. It should definitely be trustless. Otherwise it's a step back technologically. Unless NTP is so established by now that it can be relied upon. That could be worth investigating. The Internet itself is actually not trustless. NTP I assume is a very battle tested protocol.

You are saying nothing but "I want this, I want that" without really knowing what you are talking about.

The Bitcoin miner network IS already a distributed time server. Due to its decentralized nature its resolution could not be too high. If you believe you are able to create an even better distributed time server than the miner network, just do it.

Granted, I don't know much about the technical details of Bitcoin so it may be a bit over my head. Anyway, the main idea is that instead of the miners reaching a target they have a deadline. This means zero variance and very fast transaction times. The miners would still get the usual reward in bitcoins (25 at the moment I think) and the transaction fees. Another difference is that yes Bitcoin is a timestamp server but not a real-time one. I don't know much about distributed systems, so that's why I posted this thread without having my own solution to it in terms of implementation.

I've been meaning to put Anders on ignore for a while now.  This thread finally reminded me to do it.

I'm getting a bit bored with his poorly thought out, hey, let just do the following and all the problems of the world will be solved:

• Step 1. Collect underpants
• Step 2. ?
• Step 3. Profit

The number of newbies that show up here thinking that their ideas are brand new and nobody has bothered to think of them in the past 6 years just astounds me.

I'm not saying that a newbie can't come up with an original idea, just that most of them don't, and none of them seem to even consider the possibility that their idea isn't new and that they should learn a bit about what has already been discussed regarding their idea before they present it as revolutionary.

The variance in Bitcoin today could lead to transaction times of several hours! The probability for that may be exceedingly small, yet remember Murphy's law.

Let me tell you a true story about Nobel laureates in economics who developed a "foolproof" model for derivatives trading or something like that. The model worked wonderfully until one day the stockmarkets dropped more than "they are supposed" to do, leading to a catastrophic crash of their entire model.

So what, you may think. An occasional long transaction time would only be like a bump on the road. Again, consider Murphy's law where Bitcoin has become mainstream and several financial systems rely on Bitcoin transaction times being less than two hours.

Another problem to consider: How many bitcoin transactions per 10 minutes are done today? Around 400 perhaps. Compare that with the millions and millions ordinary money transactions per ten minutes happening in the world today. If Bitcoin is supposed to become anywhere near mainstream, it would have to cope with several orders of magnitude increase in number of transactions. Block chain bloat, anyone?

Propose attack:

1. I select my own nonce, and generate block with it (maybe, spend some work resources).
2. I send fake time-message (with senderIP and so on belong to official time-server), contains my own nonce,
a little earlier, than official time server.
And, instantly, send block to my peers.
 

Yes, pretty much.  That's the entire point of mining.

Bitcoin-like things work because the earliest transaction is the valid transaction, and later ones are invalid and orphaned.  The trouble was how do you know what's earliest?  Your clock might be wrong.  Outside sources might lie to you.  Information propagation takes time.  And on top of it, when money is involved, you have to assume everybody else is trying to lie and cheat and steal from you.  And that on top of THAT, you want the system to be able to work with nodes coming on and offline, and they need to be able to download updates and KNOW, not trust, that they are accurate.  Sure, a signature could contain a timestamp, but the signer might have just lied, even if he had accurate information.

So how the hell do you solve that?

By not relying on time, but instead relying on WORK.  Churning through sha hashes until you find one within a specific range.  If we assume sha hashes are not predictable, then we know that if you found a specific hash, you HAD to have, on average, churned through some number of hashes.  And given that it takes TIME to calculate a hash, we know that it will on average take some amount of time to do that work.  Now we have a basis for coordinating our clocks.  We may not know the exact time, but we CAN quite easily verify that work has been done, and we know that that work HAD to have taken some amount of time.

So now we can all synchronize our clocks, not by time, but by the longest valid chain of work done, because we know that it could not possibly have been faked.  The work WAS done.  The valid hash is proof of that.  And now, we can have nodes coming on- and off-line, lying to us, and on and on, and all we have to do is get somebody, anybody, to send us the valid chain, and we'll know it's valid, because we can check it very easily, and we've all agreed ahead of time that the longest ("longest" meaning most work) valid chain is the real chain.

Yes, bitcoin mining's whole purpose is to solve the distributed time server problem in a TRUSTLESS manner.  The purpose of doing the work is to PROVE that time has elapsed.  The transaction with more work done on top of it is OLDER.  Thus, we can now verify which transaction came first.

If you can solve the time server another way, you will have done what nobody could do for decades until Satoshi.  Go for it.

The other miners would check your nonce and see that it differs from the UTC timestamp and therefore reject your block.

If the distributed clock server is wrong it will not work. My idea depends on the real-time clock being reliable.

> The other miners would check your nonce and see that it differs from the UTC timestamp and therefore reject your block.

How miners understand, which time message is valid?

I remind: I send fake time message, contains my nonce.  Time-server also will send valid time-message, contains it's own nonce.
Miner receives two time-messages. My message little earlier, message from server little late.

To which message it will be trust?

You can say now: "time server can sign message with public cryptography signature. And, fake message is impossible."

I will answer:

OK. If so, you propose centralized system, depends on single time-server with single signature.
If that server will be done, all your payment network will freeze.

In addition, your system give unlimited power to manipulate with blockchain for time server owner.
He can generate any blocks himself, without problems. And by this way - can create/cancel transations as he wish.

If so - maybe, we can just resign, move all coin accounts into TimeServer's computer?

The miners look for the distributed time server for the correct real-time UTC timestamp. Be it with NTP or some other protocol. Fraud miners will be unable to fake that. That's like a claim: today is the year 2015. And the distributed time server says: no, it's not, today is the year 2014.

Who will be allowed to set up NTP servers? Anybody! But the miners will connect to the established NTP servers. Reliable. Proven. Tested and with roots in the 1980s! Fraud time servers = rejected.

And where, pray tell me, is the incentive then for setting up Bitcoin servers? The miner reward is still needed. Unless there is either voluntary Bitcoin servers or servers run by governments. You want to stick with up to over one hour transaction times? Will not work in the long run. And even altcoins with only like 1 minute transaction time, doomed to failure.

My prediction is that a cryptocurrency regulated and run by governments can use something like PoM, with two-second transaction times and with zero transaction fees, and with a user ID system that removes the dark ages need to store coins "under the mattress".

interesting concept - (ignore my trust rating; people just hate me)

Why do you say that (traditional PoW crypto) with under 1 min block times are doomed?

just out of interest?

The Starbucks use case I posted was a bit funny, but there is truth to that I think. One solution is 0-confirmation transactions.

"The intrinsic danger to accepting a zero confirmation transaction on the Bitcoin network, or any altcoin network, is that of the sender committing a double spend attack.  However, given the finite number of Bitcoin nodes at any given time, it is possible to use math and verify in real time that a second (double) spending does not and will not enter the Blockchain." -- http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13

If zero-confirmation transactions can be made as fast as less than say four seconds and be safe enough, then ok, then even bitcoin would be good enough for ordinary purchasing use. I have my doubts though. If any cryptocurrency is to become mainstream I think real transaction times of around two seconds are needed.

A fellow South Park (http://youtu.be/tO5sxLapAts) aficionado, I see.

It would be fun to test the idea in practice on a small scale. Lots of tedious work needed though. And I would have to learn a lot in order to be able to implement even just a part of it.

As gmaxwell pointed out, there wouldn't even need to be any miners. For example if the incoming transactions get timestamped, then each block could contain an ordered list of all the transactions for the time interval. And the servers then simply add the new blocks to the block chain. If a fraud server adds a fake block then that block will be rejected by the honest servers. This means still 51% attack risk I guess.

Would zip compression help to reduce the size of the block chain? Probably a little bit at least.

How will the servers be compensated? They will not be. :D It would be more like BitTorrent.

thanks for the feedback -

I think zero confirmations are possible for a number of reasons - common sense prevails, at a value point ( price) payment processors should/could roll with zero and use "insurance" to buffer the difference.

on a zero fee (core base) like Quark that makes sense as the payment processor can add more profit (though fees) ( the market will determine).

then anything that goes above the "zero confirm value"  has confirmations added , these would be any online or "non face to face" transactions.

to the degree that for example a some online businesses can ask for 20 Confirms - (QRK are 30 seconds)

so its a use case - value and common sense.



as for your idea - i say do it ! sounds like a great thing to test.

It would be fun to test but I know too little about how to actually implement it. And without miners the name would have to be changed to something like Proof of Nada. ;D Or maybe miners are needed, because who else would mint the coins? ???