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.
Topic: Double spend with zero confirmations has been solved. (Read 5853 times)
Some new input on VNL here https://bitcointalksearch.org/topic/m.12195905 read from this post and on.
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.
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.
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.
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.
https://talk.vanillacoin.net/topic/197/version-0-3-2-rc1-alpha-release
Enjoy breaking it if you can.
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.
Quote
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
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
Quote
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://bitcointalksearch.org/user/stephen-gornick-2228) are bad sources?
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.
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.
@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.
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.
@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.
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.
@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.
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.
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
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.
Quote
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
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
Quote
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..
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.
Quote
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
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
He states IF anyone could do vote rigging with tons of resources wasted all you could achieve is stopping ZeroTime transactions, thus the system waits for the default 1 confirmation.
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.
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.
That's the whole point of a sybil attack, in a system where impersonating multiple identities has zero cost (no wasted resources) you can easily have majority bad actors.
Once you have a majority of bad actors, you could easily imagine a scenario in which two different conflicting transaction locks are 'applied' because the majority of bad actors just lie to the rest of the network.
John on sybil attacks regarding ZeroTime: https://talk.vanillacoin.net/topic/193/john-connor-irc-quotes
To be honest, this is why I don't go on IRC - these responses are rushed and barely intelligible.
Quote
Sybil attacks are not possible. Botes cannot be forged because the top K votes are used.
and then we have
Quote
In that sense vote rigging can only prevent ZT confirmations. Not Harm. However the vote rigging odds are < 2%.
So on the one hand he says you cannot rig votes, and then just below he gives a constant probability of rigging, which is what all these systems eventually come down to.
Quote
A longer chain can never become valid since the locks remain the blocks will never be accepted.
This implies that transaction locks persist forever, but this is obviously not the case, since RAM is limited.
He states IF anyone could do vote rigging with tons of resources wasted all you could achieve is stopping ZeroTime transactions, thus the system waits for the default 1 confirmation.
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.
For me it comes down to this:
from the whitepaper
The attack will NOT result in a double spend but it does force the receiver to wait for 1 confirmation. So I don't see how ZT solves anything if I should prob wait for 1 confirmation just to make sure.
If the nodes are being chosen randomly - compared to instantx - then how is this not vulnderable to sybill attacks ? The more nodes I controll the more likely it becomes they are chosen. So I don't think it's random (allthough I don't see any quality assessment in the calculation of the voting score).
I'm by no stretch an expert so could someone point out what exactly it is I'm missing ? You can hardly expect everyone having questions to go through all the code.
from the whitepaper
Quote
2. Lock Race Attack
In a lock race attack the sender forms two transactions and two locks and
submits one to the merchant and the other to the rest of the network. In this
case the locks will cancel each other out and the transaction MUST wait for
block inclusion before being considered confirmed.
In a lock race attack the sender forms two transactions and two locks and
submits one to the merchant and the other to the rest of the network. In this
case the locks will cancel each other out and the transaction MUST wait for
block inclusion before being considered confirmed.
The attack will NOT result in a double spend but it does force the receiver to wait for 1 confirmation. So I don't see how ZT solves anything if I should prob wait for 1 confirmation just to make sure.
If the nodes are being chosen randomly - compared to instantx - then how is this not vulnderable to sybill attacks ? The more nodes I controll the more likely it becomes they are chosen. So I don't think it's random (allthough I don't see any quality assessment in the calculation of the voting score).
I'm by no stretch an expert so could someone point out what exactly it is I'm missing ? You can hardly expect everyone having questions to go through all the code.
John on sybil attacks regarding ZeroTime: https://talk.vanillacoin.net/topic/193/john-connor-irc-quotes
To be honest, this is why I don't go on IRC - these responses are rushed and barely intelligible.
Quote
Sybil attacks are not possible. Botes cannot be forged because the top K votes are used.
and then we have
Quote
In that sense vote rigging can only prevent ZT confirmations. Not Harm. However the vote rigging odds are < 2%.
So on the one hand he says you cannot rig votes, and then just below he gives a constant probability of rigging, which is what all these systems eventually come down to.
Quote
A longer chain can never become valid since the locks remain the blocks will never be accepted.
This implies that transaction locks persist forever, but this is obviously not the case, since RAM is limited.
Oh, please. Strikingly? Won't even bother responding.
Fair enough.
For anyone else wondering what I mean by strikingly, here are some excerpts from the dash paper:
Quote
In this paper we will introduce the masternode network as observer network, utilising a distributed consensus and locking algorithm “TX locking”
Quote
Utilizing this code, we can make a deterministic list of the Masternodes that will act as the authority for the transaction lock. These will be the same nodes across the network and they will vote on the validity of the transaction lock in question
https://www.dashpay.io/instantx/
So, we have the same transaction locking idea, a voting system for the consensus and the idea of different classes of nodes which perform this work.
For the record, instantx has exactly the same problems as zero time - sybil attack. The basic idea is that the cost of impersonating multiple different nodes is cheap / constant and once you have many such nodes at your disposal, the attack costs zero resources.
The only proven solution to sybil attack is POW.
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.
Oh, please. Strikingly? Won't even bother responding.
Fair enough.
For anyone else wondering what I mean by strikingly, here are some excerpts from the dash paper:
Quote
In this paper we will introduce the masternode network as observer network, utilising a distributed consensus and locking algorithm “TX locking”
Quote
Utilizing this code, we can make a deterministic list of the Masternodes that will act as the authority for the transaction lock. These will be the same nodes across the network and they will vote on the validity of the transaction lock in question
https://www.dashpay.io/instantx/
So, we have the same transaction locking idea, a voting system for the consensus and the idea of different classes of nodes which perform this work.
For the record, instantx has exactly the same problems as zero time - sybil attack. The basic idea is that the cost of impersonating multiple different nodes is cheap / constant and once you have many such nodes at your disposal, the attack costs zero resources.
The only proven solution to sybil attack is POW.
Jump to: