Pow is the thing of past, Now it's time for Port

[harshitg]

"Proof of round trip" - A new consensus for blockchain
Check this out please
Url - www.harshitgambhir.com/port.pdf

[qwk]

"Proof of round trip" - A new consensus for blockchain
Check this out please
Url - www.harshitgambhir.com/port.pdf

Your paper doesn't consider possible attack vectors (e.g. what about "artificial" round-trip-delays).

[harshitg]

"Proof of round trip" - A new consensus for blockchain
Check this out please
Url - www.harshitgambhir.com/port.pdf

Your paper doesn't consider possible attack vectors (e.g. what about "artificial" round-trip-delays).

Hi, Can you please elaborate ? What you mean by artificial round trip delays?

[qwk]

Hi, Can you please elaborate ? What you mean by artificial round trip delays?

A simple attack vector: split the chain, let the "original" chain have whatever round-trip delays it has.
Create a second, "fake" chain with slightly longer delay "values" written into the blocks (since you control the software of all the nodes of the fake chain, you can simply overwrite the values of round-trip delay).

After a while, you'll have a fake chain available that's got blocks with longer delay times, but you have it earlier than the original chain.
You can then simply replace the original chain at the exact point in time when your fake chain is "plausible".

Haven't really thought this through, so far, but I guess it's a viable attack vector to consider.

[harshitg]

A simple attack vector: split the chain, let the "original" chain have whatever round-trip delays it has.
Create a second, "fake" chain with slightly longer delay "values" written into the blocks (since you control the software of all the nodes of the fake chain, you can simply overwrite the values of round-trip delay).

After a while, you'll have a fake chain available that's got blocks with longer delay times, but you have it earlier than the original chain.
You can then simply replace the original chain at the exact point in time when your fake chain is "plausible".

Haven't really thought this through, so far, but I guess it's a viable attack vector to consider.

I think you have misunderstood the paper. Don't worry i will explain.
Only changing the delay value in the block does not make it valid because nodes have to send the block with same round-trip delay(or latency) to other nodes.
Suppose an attacker forks the chain at block "X" and some blocks have been added after block "X". Attacker chances will be very low because even if attacker sends the blocks with highest round trip delays possible he will not be able to catch the main chain as the blocks are kept adding on the main chain.

[qwk]

A simple attack vector: split the chain, let the "original" chain have whatever round-trip delays it has.
Create a second, "fake" chain with slightly longer delay "values" written into the blocks (since you control the software of all the nodes of the fake chain, you can simply overwrite the values of round-trip delay).

After a while, you'll have a fake chain available that's got blocks with longer delay times, but you have it earlier than the original chain.
You can then simply replace the original chain at the exact point in time when your fake chain is "plausible".

Haven't really thought this through, so far, but I guess it's a viable attack vector to consider.

I think you have misunderstood the paper. Don't worry i will explain.
Only changing the delay value in the block does not make it valid because nodes have to send the block with same round-trip delay(or latency) to other nodes.
Suppose an attacker forks the chain at block "X" and some blocks have been added after block "X". Attacker chances will be very low because even if attacker sends the blocks with highest round trip delays possible he will not be able to catch the main chain as the blocks are kept adding on the main chain.

That's why you'd have to create a "split" in the first place.
You have two separate networks, the fake one will accept my fake blocks, since it runs entirely on my nodes, with my software.
The consensus mechanism will then merge the fake network and the real network once they come into contact again, applying the consensus rules, which will result in the longer chain (in that case the fake chain) being accepted as the real chain, thus orphaning the original real chain.

[KingScorpio]

"Proof of round trip" - A new consensus for blockchain
Check this out please
Url - www.harshitgambhir.com/port.pdf

an encription is an encription, it will be in the long term insignificant what kind of a tech is being used.

even if an encription service like ethereum or waves is being used, it is still an encription and the tech basis can be interchanged.

who the hell cares, what tech is being used today to print usd, or euros?

no one cares.

same will be with crypto in the long term.

even if you create a "namecoin" that is not ressourceintense, it still stays a simple encription, question will be what does it stand for?

i therefore recommend to not try to sell tech based token, you can only sell an encription technology.

selling a techtoken is like selling certificates only for the technology that zertified them.

[harshitg]

A simple attack vector: split the chain, let the "original" chain have whatever round-trip delays it has.
Create a second, "fake" chain with slightly longer delay "values" written into the blocks (since you control the software of all the nodes of the fake chain, you can simply overwrite the values of round-trip delay).

After a while, you'll have a fake chain available that's got blocks with longer delay times, but you have it earlier than the original chain.
You can then simply replace the original chain at the exact point in time when your fake chain is "plausible".

Haven't really thought this through, so far, but I guess it's a viable attack vector to consider.

I think you have misunderstood the paper. Don't worry i will explain.
Only changing the delay value in the block does not make it valid because nodes have to send the block with same round-trip delay(or latency) to other nodes.
Suppose an attacker forks the chain at block "X" and some blocks have been added after block "X". Attacker chances will be very low because even if attacker sends the blocks with highest round trip delays possible he will not be able to catch the main chain as the blocks are kept adding on the main chain.

That's why you'd have to create a "split" in the first place.
You have two separate networks, the fake one will accept my fake blocks, since it runs entirely on my nodes, with my software.
The consensus mechanism will then merge the fake network and the real network once they come into contact again, applying the consensus rules, which will result in the longer chain (in that case the fake chain) being accepted as the real chain, thus orphaning the original real chain.

Forking is possible only to newly formed chain as the chain increases to more blocks, the probability will decrease because nodes can only have max delay of 65279ms per block so they can not go far from this range in generating blocks.

[qwk]

That's why you'd have to create a "split" in the first place.
You have two separate networks, the fake one will accept my fake blocks, since it runs entirely on my nodes, with my software.
The consensus mechanism will then merge the fake network and the real network once they come into contact again, applying the consensus rules, which will result in the longer chain (in that case the fake chain) being accepted as the real chain, thus orphaning the original real chain.

Forking is possible only to newly formed chain as the chain increases to more blocks, the probability will decrease because nodes can only have max delay of 65279ms per block so they can not go far from this range in generating blocks.

65279ms actually seems to leave enough room for very long splits / forks.
But no matter what threshold of delay you set, as long as it's an arbitrary number, there's an attack vector in the range below.
Granted, that will probably render double-spend-attacks for anything longer in the past than the arbitrary number moot.

[Indamuck]

Proof of work probably won't last, the security it produces is overhyped because even shitcoins aren't getting attacked.  It is a terrible waste of energy and it just rewards dumpers.  Once Proof of stake gets fully figured out it will be the dominant issuance method in my opinion.

[harshitg]

That's why you'd have to create a "split" in the first place.
You have two separate networks, the fake one will accept my fake blocks, since it runs entirely on my nodes, with my software.
The consensus mechanism will then merge the fake network and the real network once they come into contact again, applying the consensus rules, which will result in the longer chain (in that case the fake chain) being accepted as the real chain, thus orphaning the original real chain.

Forking is possible only to newly formed chain as the chain increases to more blocks, the probability will decrease because nodes can only have max delay of 65279ms per block so they can not go far from this range in generating blocks.

65279ms actually seems to leave enough room for very long splits / forks.
But no matter what threshold of delay you set, as long as it's an arbitrary number, there's an attack vector in the range below.
Granted, that will probably render double-spend-attacks for anything longer in the past than the arbitrary number moot.

You are right but fork will only occur only when multiple blocks are mined at same time or if new blocks gets stop adding to the main chain. Forks occur in proof of work also but they merge as the network founds new longest chain, In the same way proof of round-trip network will merge the fork when it sees a chain longer than the current. So blocks not matured enough are prone to attack, once new blocks added previous blocks will become less prone to attack.
Suppose if main chain have round-trip delay of 100000ms then it is impossible to generate chain having delay more than that if main chain keeps on increasing. exception - attacker is not generating chain side by side from block 0.

[KingScorpio]

Proof of work probably won't last, the security it produces is overhyped because even shitcoins aren't getting attacked.  It is a terrible waste of energy and it just rewards dumpers.  Once Proof of stake gets fully figured out it will be the dominant issuance method in my opinion.

the absolute proof of stake will only be figured out by the few, as it was always, you might even not understand what i mean with this post

[harshitg]

Proof of work probably won't last, the security it produces is overhyped because even shitcoins aren't getting attacked.  It is a terrible waste of energy and it just rewards dumpers.  Once Proof of stake gets fully figured out it will be the dominant issuance method in my opinion.

Proof of stake will remain centralized due to staking mechanism no matter what alternatives come.