Double spend with zero confirmations has been solved.

[nextgencoin]

http://vanillacoin.net/papers/zerotime.pdf

[1715606516]

1715606516

[1715606516]

1715606516

[1715606516]

1715606516

[1715606516]

1715606516

[1715606516]

1715606516

[spazzdla]

But.. It's not a problem..

The idea one thinks it's a problem points to they do not understand consensus algorithms..

The blockchain is enforced by time.. after 100 blocks one assumes we aren't forking from that.. after 5 blocks.. it's still reasonably likely a fork could happen.

[nextgencoin]

But.. It's not a problem..

The idea one thinks it's a problem points to they do not understand consensus algorithms..

Huh?

It's not a problem cause anyone who wants a safe transfer has to wait a bunch of confirmations. This now takes that need away, ie safe transfers under a second. I'm pretty sure Bitcoin can't do that.

[spazzdla]

But.. It's not a problem..

The idea one thinks it's a problem points to they do not understand consensus algorithms..

Huh?

It's not a problem cause anyone who wants a safe transfer has to wait a bunch of confirmations. This now takes that need away, ie safe transfers under a second. I'm pretty sure Bitcoin can't do that.

What if someone gets 51% for a couple hours and creates a bunch of coins....?  How do we fork out those coins?

[Fuserleer]

With the amount of hash power the BTC network has, just a single confirmation is enough for most transactions, if you are sending a large amount to an untrusted 3rd party, then 2-3 is plenty.  The effort required at that point to undo that work is pretty insane.

I've always had a small issue with the confirmation time of BTC, it could be a little faster IMO, but considering at the time BTC was released all this was a bit of an unknown, 10 minutes is a safe amount of time and isn't too inconvenient.  That 10 min confirm certainly isn't a deal breaker by any stretch of the imagination for me, nor for most other people.

I guess that the solution presented here solves potential Finney attacks to some degree, but its not a major issue and certainly isn't going to result in people en-mass leaving BTC for VNC just because a "problem" that isn't widespread has been solved.

You need much more than that to dethrone the current king.

[Lauda]

This should be moved to a more appropriate section. With time, the costs of doing such a attack become higher and higher. Bitcoin does not need this feature. However, if someone with real knowledge can actually look into it that would be good. If it isn't hard to implement, and will not cause problems, then go ahead.

[spazzdla]

Super nodes... sounds heavily centralized.

[Fuserleer]

This should be moved to a more appropriate section. With time, the costs of doing such a attack become higher and higher. Bitcoin does not need this feature. However, if someone with real knowledge can actually look into it that would be good. If it isn't hard to implement, and will not cause problems, then go ahead.

I didn't read the paper in too much detail, maybe I'll go over it and check it out.  We've had this ability to do "immediate confirmations" for quite some time now, but our ledger is not a block chain and works totally different.  

This "feature" of having transactions "confirm" in a rapid fashion for us was a side effect of how our ledger operates.  It was never something we felt the need to solve, even before the current ledger tech was implemented and gave it to us for free, because assuming you have good penetration into mass market, Finney attacks and the like will be rare because the majority of your users wont be tech savvy enough to perform them.  So long as the merchants are pro-active in ensuring that larger sized transactions are handled accordingly, the impact IMO is small, regardless of if its solved or not.

[nextgencoin]

With the amount of hash power the BTC network has, just a single confirmation is enough for most transactions, if you are sending a large amount to an untrusted 3rd party, then 2-3 is plenty.  The effort required at that point to undo that work is pretty insane.

I've always had a small issue with the confirmation time of BTC, it could be a little faster IMO, but considering at the time BTC was released all this was a bit of an unknown, 10 minutes is a safe amount of time and isn't too inconvenient.  That 10 min confirm certainly isn't a deal breaker by any stretch of the imagination for me, nor for most other people.

I guess that the solution presented here solves potential Finney attacks to some degree, but its not a major issue and certainly isn't going to result in people en-mass leaving BTC for VNC just because a "problem" that isn't widespread has been solved.

You need much more than that to dethrone the current king.

10 minutes is a looooooog time to wait at the counter in Starbucks...

[Fuserleer]

With the amount of hash power the BTC network has, just a single confirmation is enough for most transactions, if you are sending a large amount to an untrusted 3rd party, then 2-3 is plenty.  The effort required at that point to undo that work is pretty insane.

I've always had a small issue with the confirmation time of BTC, it could be a little faster IMO, but considering at the time BTC was released all this was a bit of an unknown, 10 minutes is a safe amount of time and isn't too inconvenient.  That 10 min confirm certainly isn't a deal breaker by any stretch of the imagination for me, nor for most other people.

I guess that the solution presented here solves potential Finney attacks to some degree, but its not a major issue and certainly isn't going to result in people en-mass leaving BTC for VNC just because a "problem" that isn't widespread has been solved.

You need much more than that to dethrone the current king.

10 minutes is a looooooog time to wait at the counter in Starbucks...

You don't have to wait for a confirmation though.  Starbucks can afford to take the $3 hit of 1 in 100,000 transactions being a Finney attack. 

People like to use that argument a lot to justify a ton of "issues" with BTC, and the fact is, you don't need to wait for a confirmation for most day to day transactions.

[Fuserleer]

If you think about it, a Finney attack is akin to counterfeit money, yet will probably be a lot rarer.

Is it a problem, sure it is, just like counterfeit notes, but you don't hear Starbucks or anyone else saying that they aren't going to accept cash anymore because 1 in 2000 notes are counterfeit which they accept mistakenly.  It's a hit they are willing to take, and the same is true here.

[Amph]

Super nodes... sounds heavily centralized.

as long as there is more than one you can't really call it centralized i think, i remember that super nodes, were theorized for resolving the longest chain issue and resolve the 51%, but i could be wrong

[BornBlazed]

doesn't take long too get that first confirmation right? no risk of a double spend if you wait for a single confirm before you can hand over  what the customer purchased? make sure customer is paying highest miner fee too speed up things.

[maokoto]

Although it is nice to have transactions in seconds, I think that this is not a major issue in order to exchange one coin for another, much less when one of the coins is very popular.

10 minutes is ok and much more than what regular banks offer.

[RocketSingh]

http://vanillacoin.net/papers/zerotime.pdf

Not for bitcoin, but for VanillaCoin. This post should go under AltCoin Discussion.

[TPTB_need_war]

Okay I've digested the white paper. I appreciate john-conner providing more details. That was the honorable and helpful action.

Unfortunately afaics, there are elementary attack vectors that he has not addressed in this white paper:

• No cost to being a peer, thus a Sybil attack on nodes in general. The adversary could insert a unlimited nodes if he wants to in order to dominate voting.
• How to squelch DoS attacks on the vote? A node which always votes against consensus can't be distinguished from one voting honestly since lock conflicts result in an indeterminate vote.
• He employs a Bellagio Algorithm to avoid gaming the selection of which nodes to poll for votes, so this removes the reputation weights of Skycoin's consensus, but it doesn't address the spamming of total node count nor the spamming of the lock conflict.
• Nodes are not paid for voting. If they receive bribes from the double-spender, the algorithm has no defense other than it hopes that 50% of the nodes in the network are not on-the-dole.
• Lock request spamming or DoS attacks. Are transaction fees hardcoded for the entire network?? Preset constants are anti-decentralization.

Also this algorithm requires the entire network to see all the transactions which of course won't scale without centralization, so if he is trying to enable real-time microtransactions (1 second confirmations) which could explode transaction volumes up to the 100,000s or more per second then he has a problem. Refer to the GavinCoin fork debate.

[americanpegasus]

TPTB, you are hereby tipped 20 PegasusCoin. 
 
Thank you for your expertise and hard work.

[bl234st]

While everyone is scrambling to buy some ETH I feel like Vanilla coin just became the genuine Bitcoin 2.0. Making perfect what was already great.


History making...

Oh dear!

FWIW, I politely reported the copyright violation (the code being a copy of Bitcoin Core run through an auto-formatter with all the attribution removed) as an issue on the github for the project and john-connor accused me of stalking him and then hid the issue tracker on that github from public view. :-/

I suppose I shouldn't be surprised as it's consistent with the rest of the concerns that resulted in creating this thread-- that there is some ongoing effort to keep that work out of the sunlight.

Oh double dear!!

What does Gordon, AnonyMint, Paul, and others know about synchronicity?


I trust John Conner! 

[nextgencoin]

Okay I've digested the white paper. I appreciate john-conner providing more details. That was the honorable and helpful action.

Unfortunately afaics, there are elementary attack vectors that he has not addressed in this white paper:

• No cost to being a peer, thus a Sybil attack on nodes in general. The adversary could insert a unlimited nodes if he wants to in order to dominate voting.
• How to squelch DoS attacks on the vote? A node which always votes against consensus can't be distinguished from one voting honestly since lock conflicts result in an indeterminate vote.
• He employs a Bellagio Algorithm to avoid gaming the selection of which nodes to poll for votes, so this removes the reputation weights of Skycoin's consensus, but it doesn't address the spamming of total node count nor the spamming of the lock conflict.
• Nodes are not paid for voting. If they receive bribes from the double-spender, the algorithm has no defense other than it hopes that 50% of the nodes in the network are not on-the-dole.
• Lock request spamming or DoS attacks. Are transaction fees hardcoded for the entire network?? Preset constants are anti-decentralization.

Also this algorithm requires the entire network to see all the transactions which of course won't scale without centralization, so if he is trying to enable real-time microtransactions (1 second confirmations) which could explode transaction volumes up to the 100,000s or more per second then he has a problem. Refer to the GavinCoin fork debate.

He's solving Bitcoin problems thought impossible to solve while you are a troll on a forum.....hmmm who to trust.

[r0ach]

Why does nobody use something like proof of burn to defend against sybil attacks?  Because then they would have to create an actual economic system instead of just a consensus mechanism?  We are getting to the point where it's not possible to make any progress in the cryptocurrency space if you don't address consensus & economics at the same time.  People are so desperate to avoid arbitrary variables they end up not creating anything.