Double spend with zero confirmations has been solved.

[traumschiff]

John on sybil attacks regarding ZeroTime: https://talk.vanillacoin.net/topic/193/john-connor-irc-quotes

It may be possible to do it on InstantX, but you won't do it here.

Also please don't compare paid masternodes to random super peers. ZeroTime is fully decentralized.

Please note that the full code is available on GitHub, before trying to act professional and pasting the same attack vector that 10 people did before you (and which obviously John knows about also), do a research. Audit the code and give out your official review.

07:59 <@john-connor-afk> Finny is a offline attack.
08:00 <@john-connor-afk> 6 full block confirmations
08:00 <@john-connor-afk> so at least 20 mins 3.33 x 6
08:02 <@john-connor-afk> finney only applies to PoW coins in reality when you can outhash the network

It would appear that he doesn't understand what a Finney attack is:

http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack

https://en.bitcoin.it/wiki/Double-spending#Finney_attack

It requires the attacker to be mining and controlling the content of his blocks; however, he can in theory do this with any hashrate, in particular significantly less than 50% of the network hashrate.

66% of our blocks are POS.

Also these sources are...khm..

[1714933599]

1714933599

[1714933599]

1714933599

[1714933599]

1714933599

[1714933599]

1714933599

[1714933599]

1714933599

[1714933599]

1714933599

[monsterer]

What else do you need? There is no incentive to do harm as you can't do harm. Stopping ZT is not a harm scenario just something that is less optimal since our confirmations already take a maximum of 1.5 minutes on avg. People like you heavily misinterpret how a system like this should or could work.

Here is why this doesn't actually hold true:

* As a sybil attacker, I control the majority of nodes, therefore I am able to respond in any way I chose to queries about transaction locks
* So, when I attempt a double spend, the recipient node performs a query to determine lock status, I then am able to respond that the lock is in place
* Once I receive my coins, I submit my own lock whilst simultaneously dropping the fake lock from all my majority nodes memories, such that subsequent lock takes priority and persists from the POV of any other network queries

[traumschiff]

@monsterer can I ask you if you actually checked the code that is uploaded in github?

You heavily underestimate John and keep questioning his developments on a forum where he won't respond to you. Did you or did you not audit the open sourced full ZT code?

Currently you are theory crafting on issues YOU think John has not dealt with.

[monsterer]

@monsterer can I ask you if you actually checked the code that is uploaded in github?

You heavily underestimate John and keep questioning his developments on a forum where he won't respond to you. Did you or did you not audit the open sourced full ZT code?

Currently you are theory crafting on issues YOU think John has not dealt  without reading a single line of the code available.

I have no intention of reading code. Code is, at best, an interpretation of the design. The design is key.

edit: In addition, my intention is only to help people who do not have knowledge about the intricacies of consensus design to understand the problem with a little more clarity.

[traumschiff]

@monsterer can I ask you if you actually checked the code that is uploaded in github?

You heavily underestimate John and keep questioning his developments on a forum where he won't respond to you. Did you or did you not audit the open sourced full ZT code?

Currently you are theory crafting on issues YOU think John has not dealt  without reading a single line of the code available.

I have no intention of reading code. Code is, at best, an interpretation of the design. The design is key.

/thread

Proof is in the code which he will deploy today on the public release. Either break it or review it if you are sure it's a weak design and doesn't need resources. The code is already up, you can start with it.

[traumschiff]

edit: In addition, my intention is only to help people who do not have knowledge about the intricacies of consensus design to understand the problem with a little more clarity.

You are obviously more competent in this than John. Not sure why you didn't build the first proper TCP/UDP network capable of decentralized subsecond transactions. On a sidenote, part of his code is already running in a top 15 crypto since months.

[rnicoll]

edit: In addition, my intention is only to help people who do not have knowledge about the intricacies of consensus design to understand the problem with a little more clarity.

You are obviously more competent in this than John. Not sure why you didn't build the first proper TCP/UDP network capable of decentralized subsecond transactions. On a sidenote, part of his code is already running in a top 15 crypto since months.

I'd hazard a guess at "UDP is a bloody pain to work with, and the advantages are uncertain", but that kind of gives the impression I'm against the idea - actually, I really like the idea of transaction relaying over UDP at least. I wouldn't do what I _believe_ Vanillacoin does and uses UDP without a controlling TCP channel (the whitepaper isn't too clear on that point), to the same node, but as transactions need to arrive quickly, in no specific order, and losing a few to network congestion isn't a crisis, on the face of it, it's a good idea.

[Este Nuno]

John on sybil attacks regarding ZeroTime: https://talk.vanillacoin.net/topic/193/john-connor-irc-quotes

It may be possible to do it on InstantX, but you won't do it here.

Also please don't compare paid masternodes to random super peers. ZeroTime is fully decentralized.

Please note that the full code is available on GitHub, before trying to act professional and pasting the same attack vector that 10 people did before you (and which obviously John knows about also), do a research. Audit the code and give out your official review.

07:59 <@john-connor-afk> Finny is a offline attack.
08:00 <@john-connor-afk> 6 full block confirmations
08:00 <@john-connor-afk> so at least 20 mins 3.33 x 6
08:02 <@john-connor-afk> finney only applies to PoW coins in reality when you can outhash the network

It would appear that he doesn't understand what a Finney attack is:

http://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack

https://en.bitcoin.it/wiki/Double-spending#Finney_attack

It requires the attacker to be mining and controlling the content of his blocks; however, he can in theory do this with any hashrate, in particular significantly less than 50% of the network hashrate.

66% of our blocks are POS.

Also these sources are...khm..

A stackexchange answer by noted Bitcoin expert Meni Rosenfeld and the Bitcoin Wiki itself which according to the page history was authored by sgornick(https://bitcointalk.org/index.php?action=profile;u=2228) are bad sources?

[traumschiff]

ZeroTime released. Wallet version 0.3.2

https://talk.vanillacoin.net/topic/197/version-0-3-2-rc1-alpha-release

Enjoy breaking it if you can.

[Este Nuno]

ZeroTime released. Wallet version 0.3.2

https://talk.vanillacoin.net/topic/197/version-0-3-2-rc1-alpha-release

Enjoy breaking it if you can.

I see there that the bounty is now off the table for breaking zerotime. Any particular reason why? Not planning on attempting it myself, but I would be interested in reading reports from people who try it.

[rnicoll]

I'd hazard a guess at "UDP is a bloody pain to work with, and the advantages are uncertain", but that kind of gives the impression I'm against the idea - actually, I really like the idea of transaction relaying over UDP at least. I wouldn't do what I _believe_ Vanillacoin does and uses UDP without a controlling TCP channel (the whitepaper isn't too clear on that point), to the same node, but as transactions need to arrive quickly, in no specific order, and losing a few to network congestion isn't a crisis, on the face of it, it's a good idea.

Oh, also, you get all the fun of dealing with UDP in NAT environments. Enjoy! I do not miss that at all.

[mrvegad]

Some new input on VNL here https://bitcointalk.org/index.php?topic=1157409.msg12195905#msg12195905 read from this post and on.

[DanielRo]

Almost every time I'm visiting https://blockchain.info/unconfirmed-transactions I'm seeing Double Spend transactions.
Yesterday: https://blockchain.info/address/1Ku7ajZ8wCB9fDQAhfE4WThwkVc37VzWsg?offset=50&filter=0, https://blockchain.info/tx-index/99701355
Today: https://blockchain.info/address/163cTKxPehxPi4nJ3oTHAso6eXWywfYr7N, https://blockchain.info/tx/c0e00b3e484481b449bc7185cde28afe5966de4ae39f09a48aa1d931dafcac55.

It seems that some people are trying hard to get some wrongful coins.