BitShares Forum
Main => General Discussion => Topic started by: Come-from-Beyond on February 09, 2015, 07:12:41 pm
-
Some people mentioned DevShares as a good way to test an attack on BitShares, I tend to follow the advice. Could anyone point me to an up-to-date documentation on DevShares (whitepaper and protocols)? Also, I'd like to get a permission from the community if it's possible to get.
-
BM mentioned that attacks on DevShares is not only allowed, but any profit gained is the attacker's income and others can't lay claim to it. Anyone having DevShares understands that.
-
I like this. Gonna go get some popcorn.
Sent from my SCH-S720C using Tapatalk 2
-
Good news, now I need only the documentation that is confirmed to be up-to-date.
-
CfB, I'll vote for you as a delegate. Bring some of those nice NXT folks over here, along with the ghost of BCNext, and you'll have enough power to get hired by the blockchain.
You won't miss the java. We have all you can drink.
(http://fc05.deviantart.net/fs71/f/2011/134/a/7/java_cup_by_petux7-d3gc5lp.png)
-
I support this 1000%! This needs to happen.
If the attack is successful, it demonstrates a need to modify the structure of Bitshares to be secure against it. This is important to know, and its much better for it to happen now while Bitshares is new and still small, than later on.
If the attack is unsuccessful, it increases confidence in the DPoS system.
There are several ways you could try to attack:
* Execute a successful double spend.
* Execute a nothing at stake attack: Buy devshares, use the stake to vote in delegates, sell the devshares, and then use the delegates to be malicious in some way.
* Install many paid delegates and then have them conspire to not be able to be removed from office, even if voters want them out.
* Install many paid delegates, produce no of value, but have them remain in office. (Sybil attack).
If the result of the attack is that the attacker loses a significant amount of money (relative to the cost of the shares bought to execute the attack), and the disruption to the network was not catastrophic, I would consider it an unsuccessful attack. After all, in Proof of Work once could also rent tons of hashing power and use it to perform a 51% attack, but if this is costly and not sufficiently disruptive then its not a big weakness. If the same thing occurs in DPoS then its not a real vulnerability, especially if the spend value ends up in the hands of shareholders/traders of BTS.
Note: I suspect that you might be able to execute an attack where you get many paid delegates elected and then sit there and do nothing and collect pay, MUCH more easily in devshares than in Bitshares. Bitshares has actual value, and shareholders are fairly watchful, so any paid delegates come under scrutiny. They already fired blackwavelabs after not seeing an update after 3 weeks.
Devshares is very cheap and thus it is quite possible that no one would care.
-
CfB, I'll vote for you as a delegate. Bring some of those nice NXT folks over here, along with the ghost of BCNext, and you'll have enough power to get hired by the blockchain.
You won't miss the java. We have all you can drink.
(http://fc05.deviantart.net/fs71/f/2011/134/a/7/java_cup_by_petux7-d3gc5lp.png)
I suspect if he cannot attack it he will switch over and bring in many of the NXT devs here with him...
-
CfB, I'll vote for you as a delegate. Bring some of those nice NXT folks over here, along with the ghost of BCNext, and you'll have enough power to get hired by the blockchain.
You won't miss the java. We have all you can drink.
(http://fc05.deviantart.net/fs71/f/2011/134/a/7/java_cup_by_petux7-d3gc5lp.png)
My agenda is slightly different than you may guess. I'm going to probe BitShares a little to figure out what elements of the whole BitShares mechanism could be implemented in hardware. Nxt and Ethereum are in the list too.
-
You are helping us to find the weakness in the system so that we can secure it better. All this is done in the safe environment of dvs chain. You are spending time, effort and possibly monies in this test. Thank you. Looking forward to your first attempt.
-
I think the lack of real socio-economic incentives within DevShares will make this data not very useful. The will of shareholders is an essential piece to this puzzle; people just don't care enough about DevShares.
For this attack experiment to be useful, people have to start caring about the security of its network. There will be 'attackers', and 'defenders', each putting value into the shares for different reasons. The upper bound of the token value will then be defined kind of like an auction of the two sides; who is willing to pay more to control the network?
I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.
Are you an Attacker or a Defender of DevShares?
-
I think the lack of real socio-economic incentives within DevShares will make this data not very useful. The will of shareholders is an essential piece to this puzzle; people just don't care enough about DevShares.
For this attack experiment to be useful, people have to start caring about the security of its network. There will be 'attackers', and 'defenders', each putting value into the shares for different reasons. The upper bound of the token value will then be defined kind of like an auction of the two sides; who is willing to pay more to control the network?
I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.
Are you an Attacker or a Defender of DevShares?
Valid point about DevShares not being protected enough. Maybe I should begin with the hardest target - BitShares. I hope the community doesn't mind?
-
BTW when will DVS has its price? Relative order updates are coming in two weeks but we can't test it until DvsUSD goes live.
-
I think the lack of real socio-economic incentives within DevShares will make this data not very useful. The will of shareholders is an essential piece to this puzzle; people just don't care enough about DevShares.
There are some sorts of attacks that can definitely be tested in devshares.
There are others that might work well on devshares but be much harder to execute on bitshares, because the difficulty to execute them scales with the amount that the community cares about and values the coin.
Still, I think we can learn valuable things. If it costs $X to acquire the devcoin used to attack, and in the end the attacker loses Y% of it, then possibly a similar result would hold for Bitshares. If the attacker can attack devcoin with minimal loss in percentage terms, its worrying.
-
Good idea!
-
I think the lack of real socio-economic incentives within DevShares will make this data not very useful. The will of shareholders is an essential piece to this puzzle; people just don't care enough about DevShares.
There are some sorts of attacks that can definitely be tested in devshares.
There are others that might work well on devshares but be much harder to execute on bitshares, because the difficulty to execute them scales with the amount that the community cares about and values the coin.
Still, I think we can learn valuable things. If it costs $X to acquire the devcoin used to attack, and in the end the attacker loses Y% of it, then possibly a similar result would hold for Bitshares. If the attacker can attack devcoin with minimal loss in percentage terms, its worrying.
I just think the game theory is totally different, and non-comparable. Protocol-wise it may be the same, but BitShares has social factors baked-in. Critiquing a cake baked without baking soda doesn't give you much useful data about the quality of the original recipe.
It reminds me of playing free-roll online poker. There's nothing to lose, so people go all-in every hand. They don't care, and the strategies (or lack of strategies) players employ relates very little to the strategies they employ when money is on the line.
-
I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.
But in normal conditions, there is not an extra bet riding on the outcome of whether the attack is successful. I think this would modify the incentives of the situation and thus possibly change the results.
I think that we should investigate "Is Bitshares vulnerable to attack in normal situaitons" not "Is Bitshares vulnerable to attack in situations where Bitshares holders have agreed to a bet where they will pay money to the attacker if he wins".
I definitely believe that, if you are willing to lose enough money, you can cause some amount of damage to the Bitshares network. (Same as in Bitcoin). It would be foolish for Bitshares to subsidizethe attacker. The main goal of Bitshares defense is that the attacker cannot attack without losing money, and the money goes to Bitshares holders, compensating them for the temporary disruption of the network.
-
Valid point about DevShares not being protected enough. Maybe I should begin with the hardest target - BitShares. I hope the community doesn't mind?
I prefer attacking Devshares. If successful, Bitshares can modify itself to be more resilient.
Still, I support you trying to attack Bitshares. Given that step 1 of the process is probably going to require buying bitshares, I would take advantage of the resulting price rise by selling some, and then rebuy lower when you get to the part of the plan where you dump. :)
Other possibilities are that you end up burning many BTS permanently in order to create paid delegates. If you fail to get them elected or if you keep them elected for less than 2 weeks, the net result is a reduction in BTS supply.
Failed attacks against Bitshares probably end up making it stronger!
-
Other possibilities are that you end up burning many BTS permanently in order to create paid delegates.
I'll start from a cheap attack. A successful disrupting of networking should lead to price decline and allow me to buy cheap coins, by selling them after the price returns to the old levels I'll get free money for more sophisticated attacks.
-
Other possibilities are that you end up burning many BTS permanently in order to create paid delegates.
I'll start from a cheap attack. A successful disrupting of networking should lead to price decline and allow me to buy cheap coins, by selling them after the price returns to the old levels I'll get free money for more sophisticated attacks.
* If you can successfully make a significant network disruption for cheap then your attack is successful and you would have shown a vulnerability in BTS. No need for a phase 2 more expensive attack in that case.
* A network disruption would probably have to be very significant and lasting in order to have an impact on the price. Several versions ago the devs introduced a bug which caused many forks. A lot of delegates were on various forks over the next 24 hours, but the price didnt react. Given that BTS is relatively new and is under constant development, I think the market expects bugs and disruptions occasionally, and would only respond to a very serious disruption.
If BTS were a lot more mature, then maybe a short term disruption would have more impact. By that point however, we wont be seeing new versions of bitshares nearly as often.
-
I hope this isnt one of those omg i found an attack vector and u better pray i dont use it but then nothing happens price crashes and he gets cheap coins... Like monero except like i predicted they got left holding the bag they "thought" that they bought cheap.. We all know this type of attack doesnt end up well for attacker or investors in short term based on what we saw last few times
If true then im pretty sure it only is win win.. He she should just buy at market because any negative attention will not affect price from this persons
-
I doubt that the attack plan is simply to loudly proclaim "I will attack Bitshares" and then hope you can make people panic and sell. That isn't a real attack, its merely an attempt at market manipulation, and I'm pretty sure that Come_from_beyond is much better than that.
Even if that was the case, you would simply divide people into NXT supporters cheering for Come_from_beyond's attack, versus Bitshares supporters thinking it wont work, and everyone will just defend their tribe's position.
Every coin is vulnerable to market manipulation anyway, so such an attack would show nothing.
-
I think this should be a competition, with defined rules, and money put up by both sides. The pot is split up proportionately to the donations of the side that wins. This will double as a prediction market indicator of the success of the attack.
But in normal conditions, there is not an extra bet riding on the outcome of whether the attack is successful. I think this would modify the incentives of the situation and thus possibly change the results.
I think that we should investigate "Is Bitshares vulnerable to attack in normal situaitons" not "Is Bitshares vulnerable to attack in situations where Bitshares holders have agreed to a bet where they will pay money to the attacker if he wins".
I agree. This would change the results, allowing to closer represent a realistic scenario. By holding BTS, you are implicitly betting on its security model. The security of a token gives its value proposition breadth. As confidence in security drops, a token's value trends toward zero very quickly, disproportionately. Since DevShares are explicitly 'hold at your own risk, hackers encouraged', this has a big effect on its token value. If people hold them knowing they could lose them at any time, they must be okay with this fact. If you are ok with losing something at any time, there is no resistance against hackers. If there is no resistance against hackers, then testing for vulnerabilities could lead to uselss results.
Your qualification of
"Is Bitshares vulnerable to attack in normal situations"
does in fact not fit with DevShares, as DevShares does not harbor a 'normal situation'. By putting money on the table, you're making the situation much closer to that of BitShares. If you interpret your negative qualification
"Is Bitshares vulnerable to attack in situations where Bitshares holders have agreed to a bet where they will pay money to the attacker if he wins"
as "Is BitShares vulnerable to attack in situations where BitShares holders will lose money", then having them place bets results in a more similar scenario, and more similar game-theory / socioeconomic climates.
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work. If you go about it this way, then attacking BitShares directly may be a viable option. If you bring up a vulnerability that the community/devs declare is real, then we will fix it.
If you prove to be a valuable asset for our security, you may be a viable candidate for becoming a delegate and receiving pay.
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.
Good idea, will do it this way.
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
-
as "Is BitShares vulnerable to attack in situations where BitShares holders will lose money", then having them place bets results in a more similar scenario, and more similar game-theory / socioeconomic climates.
The way I see it, Bitshares holders are in a constant state of betting that Bitshares will not suffer from attacks (as an attack would decrease the value of their holdings).
But if they also make an extra 'bet', they are in essence subsidizing any possible attack.
For example, if I can attack Bitshares for a cost of $X, and you offer my a bet of more than $X if I successfully attack, then you have simply opened yourself up to a vulnerability. I take your bet, spend $X attacking, then collect and make a profit.
Bitshares best defense against attacks, imo, is that they not only cost money, but the money ends up in the hands of BTS holders and/or traders in the end. Either through a failed nothing at stake attack, where the attacker loses money due to slippage when buying and selling BTS. Or due to the scenario in case of a severe attack which Bytemaster has described, in which the community responds by hard forking Bitshares, cutting out the malicious stake, and proceeding on as before, but with a lower effective BTS supply. In the end, humans play a role in the Bitshares consensus algorithm.
I would not want BTS holders to make a bet that Bitshares can be attacked, because this might subsidize the attack.
I would like for the attacker to lose money on the attack (whether successful or a failure), and that money go to BTS holders in some way.
I believe that Come_from_beyond could disrupt Bitshares, given a willingness to lose enough money. I just don't think he can do it for cheap.
-
If you prove to be a valuable asset for our security, you may be a viable candidate for becoming a delegate and receiving pay.
I would definitely vote for Come_from_beyond as a delegate. I wouldn't vote for him to have 10 delegates so he could attack us though, hehe. :P (I don't think I could support more than 2 delegates for any individual, and wold allow 2 only as a temporary measure until such time as our share price returns to the 3 cent range). We need to remain decentralized.
Of course, if he was elected I would expect something to be produced, such as academic research/whitepapers on whether Bitshares was vulnerable to certain types of attacks, with empirical testing. That would be quite valuable, imo!
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.
Good idea, will do it this way.
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
+5%
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.
Good idea, will do it this way.
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...
-
Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...
It is easier to defend because we can strengthen that weakness before the attack takes place. This is a desirable outcome.
-
My agenda is slightly different than you may guess. I'm going to probe BitShares a little to figure out what elements of the whole BitShares mechanism could be implemented in hardware. Nxt and Ethereum are in the list too.
you made me curious. care to explain more? please
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.
Good idea, will do it this way.
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...
One of the elements for a successful attack is 'surprise'. If we take this element out, I doubt it can have a successful outcome.
-
Come-from-Beyond, here's a nice honest way to approach this: discuss with the community what kind of attack you plan on doing before executing it, and then proceed with the attack only if the devs/community tell you that your particular attack will not work.
Good idea, will do it this way.
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
Is it not easier to defend from an attack when it is known how and when it will be executed?
I would say the first step is to attack DevShares without informing the community when and how it will happen...
One of the elements for a successful attack is 'surprise'. If we take this element out, I doubt it can have a successful outcome.
If the goal is to damage the network, this is true. If the goal is to strengthen the network by discovering any vulnerabilities, then it depends on the nature of the vulnerability.
If the weakness is clearly apparent once attention is brought to it, there's no need to actually exploit it to demonstrate that it exists. If a more subtle and controversial weakness exists, a demonstration on either DevShares or the main network might be required.
I appreciate Come-from-Beyond's efforts on this, and am also curious about his hardware angle.
-
Right, there only needs to be a surprise if there is actual malicious intent. If there exists a known vulnerability that only works when it is unanticipated, then either a) it needs to be always anticipated or b) something needs to be fixed to no longer need to constantly anticipate. In either case, in terms of strengthening the network, nothing is gained by exploiting this kind of vulnerability if it is known.
-
Right, there only needs to be a surprise if there is actual malicious intent. If there exists a known vulnerability that only works when it is unanticipated, then either a) it needs to be always anticipated or b) something needs to be fixed to no longer need to constantly anticipate. In either case, in terms of strengthening the network, nothing is gained by exploiting this kind of vulnerability if it is known.
If the exact details of an attack is known, wouldn't the voters and community members be actively monitor and defend against it? The apathy voters would suddenly spring into life and monitor the forum thread frequently. These are the things that they do not do in any usual day. And if the attack can fail so easily due a pre-warn, what kind of credibility (or rather 'discredibility') would Come-from-Beyond get out of it? Would he spend the time, effort and monies to get this result?
-
We need to have DevShares listed somewhere to give it some value. Maybe Bter or Yunbi will be willing to do so.
-
you made me curious. care to explain more? please
I appreciate Come-from-Beyond's efforts on this, and am also curious about his hardware angle.
We are developing a processor that will support distributed computing on hardware level. Here you can see what it will look like for a programmer - https://nxtforum.org/jinn/programming-model/. This implies that blockchain tech will be supported at the lowest possible level.
PS: No need to type my nickname completely, "cfb" is enough. :)
-
I think it's an interesting approach. Let us know what you find. Nothing but good can come from this imo.
-
Is BitShares code based on Bitcoin? If yes, is BitShares networking code based on Bitcoin? If no, is there a textual description of the peer communication protocol (reading code written in a language I'm not familiar with is not very easy)?
-
0.6.0 is the latest version and https://github.com/BitShares/bitshares/archive/bts/0.6.0.zip is the source code, right?
Actually it's 0.6.1 now.
Is BitShares code based on Bitcoin? If yes, is BitShares networking code based on Bitcoin?
No, BitShares is written from scratch. (Although it does borrow a few things from 3rd party code.)
If no, is there a textual description of the peer communication protocol (reading code written in a language I'm not familiar with is not very easy)?
Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page
-
So the newly designed processor which supports distrbited computing will be better? But in what sense? Efficiency, scalability or what?
How does studying dpos, nxt and ethereum help?
-
Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page
I didn't check them. After this case (https://bitcointalk.org/index.php?topic=940298.msg10405564#msg10405564) I don't trust documentation if it's not confirmed that it's actual.
-
So the newly designed processor which supports distrbited computing will be better? But in what sense? Efficiency, scalability or what?
How does studying dpos, nxt and ethereum help?
With the new processor computation and storage load could be split among several nodes simply by connecting them to each other. If Alice can't store the whole blockchain then she could ask Bob to help her. Everyone of them will be storing only half of the data.
The best way to study something is to try to break it. I used to use this method since early childhood. When I know more I'll be able to decide what is already provided in hardware and what should be added.
-
Many details about BitShares are still in flux, so I doubt there is up-to-date documentation on technical details. Have you checked these wikis:
https://github.com/BitShares/bitshares/wiki
http://wiki.bitshares.org/index.php/Main_Page
I didn't check them. After this case (https://bitcointalk.org/index.php?topic=940298.msg10405564#msg10405564) I don't trust documentation if it's not confirmed that it's actual.
You are right. I am afraid there is not much of an up-to-date technical documentation. But the two links below may be of help to you:
1) https://bitsharestalk.org/index.php?topic=5164.msg68160#msg68160
2) https://bitsharestalk.org/index.php?topic=4009.msg66308#msg66308
-
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
1. Connect to as many nodes as possible.
2. Memorize time moments when nodes share a new block.
3. Analyze block travel graph trying to find its origin.
2nd phase is to check if anti-spam is used:
1. Prepare a list of already confirmed transactions.
2. Feed our own node with as many transactions as possible measuring CPU usage (signature validation, double-spending prevention, etc. require a lot of CPU cycles).
3rd phase is to disrupt unconfirmed transactions processing (if there is no anti-spam):
1. Feed the next delegate with as many transactions as possible.
2. Check if the generated block contains only a fraction of pending unconfirmed transactions.
This attack is easily counteracted with Hashcash-like spam prevention. If there is no anti-spam or it's not effective enough then the attack should be extended to DoS all delegates one by one.
So, what are odds that the attack will succeed to noticeable slow down inclusion of transactions into blocks?
-
every TX you send to the network will have to validate .. especially concerning the min. relay fee ..
my guess would be that such an attack is "expensive" .. though probably no too expensive in devshares ..
this would also show an upper limit for TPS that can be handled by that particular delegate .. results would be very interesting
-
every TX you send to the network will have to validate .. especially concerning the min. relay fee ..
my guess would be that such an attack is "expensive" .. though probably no too expensive in devshares ..
this would also show an upper limit for TPS that can be handled by that particular delegate .. results would be very interesting
This is the point of the attack. If validation requires much more resources than to send a transaction then you get a big advantage. If the ratio is 100:1 then for every cent you spend the victim will spend one dollar.
-
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
How much worth is it for you when some delegates like me change their ip address about 3 times per week?
And that is a proposal/suggested defense for all delegates :)
Change your ip address every now and then .... ;)
-
How much worth is it for you when some delegates like me change their ip address about 3 times per week?
And that is a proposal/suggested defense for all delegates :)
Change your ip address every now and then .... ;)
If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).
-
How much worth is it for you when some delegates like me change their ip address about 3 times per week?
And that is a proposal/suggested defense for all delegates :)
Change your ip address every now and then .... ;)
If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).
possible countermeasure: http://digitalgaia.io/backbone.html
-
How much worth is it for you when some delegates like me change their ip address about 3 times per week?
And that is a proposal/suggested defense for all delegates :)
Change your ip address every now and then .... ;)
If I'm connected to almost all nodes then I'll detect your new IP almost instantly with high probability if you change IP and reconnect right away. If you wait some period of time then I have to analyze block travel graphs again, but this time I can exclude 99% of the nodes because I already know that they are not you. So the time for re-detection is very small compared to the time required for the initial delegate IP detection (it heavily depends on the total number of the nodes).
We need a mechanism to defend against spam and ddos attacks. If the network can expand to delegates beyond the 101 ie (102th, 103th...) during a spam/ddos attack, it would make it more expensive to the attacker.
-
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
Delegate nodes should not allow incoming connections. There is a flag set to disable incoming connections just for this purpose.
-
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
Delegate nodes should not allow incoming connections. There is a flag set to disable incoming connections just for this purpose.
then I must make a proposal ...
when a delegate runs the command:
"wallet_delegate_set_block_production "
and he change it to "true"...
the client could show a message that suggest the delegate to make exactly what you described... I assume the majority have not disabled incoming connections yet :-[
PS
"Easily Configure a Host-Based Firewall on Ubuntu to Block Incoming Connections"
http://blog.nowherelan.com/2014/01/14/easily-configure-a-host-based-firewall-on-ubuntu-to-block-incoming-connections/
PSS what happens if somebody tries to attack all seed-nodes at once? (incoming connections must be enabled
for them)
-
Delegate nodes should not allow incoming connections. There is a flag set to disable incoming connections just for this purpose.
Ok, then I'll flood the network with sybil identities and delegates will connect to my nodes in 9 of 10 cases.
-
I have disabled incoming connections for my delegate. So cfb, you have one less avenue to attack.
-
I have disabled incoming connections for my delegate. So cfb, you have one less avenue to attack.
I was planning to use Sybil attack as part of deanonymization attack on TITAN, so I wouldn't feel myself comfortable even with disabled connections...
-
I have disabled incoming connections for my delegate. So cfb, you have one less avenue to attack.
Count me in ..
DDOSing seesnodes will just prevent new clients from finding seeds .. everyone can go on P2P style :)
-
Attack scenario
1st phase is to find IP addresses of the delegates if they are not known:
1. Connect to as many nodes as possible.
2. Memorize time moments when nodes share a new block.
3. Analyze block travel graph trying to find its origin.
2nd phase is to check if anti-spam is used:
1. Prepare a list of already confirmed transactions.
2. Feed our own node with as many transactions as possible measuring CPU usage (signature validation, double-spending prevention, etc. require a lot of CPU cycles).
3rd phase is to disrupt unconfirmed transactions processing (if there is no anti-spam):
1. Feed the next delegate with as many transactions as possible.
2. Check if the generated block contains only a fraction of pending unconfirmed transactions.
This attack is easily counteracted with Hashcash-like spam prevention. If there is no anti-spam or it's not effective enough then the attack should be extended to DoS all delegates one by one.
So, what are odds that the attack will succeed to noticeable slow down inclusion of transactions into blocks?
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.
However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.
-
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.
However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.
So my attack was deflected. Ok, the next one:
Attack scenario
I flood the network with sybil nodes and start monitoring transaction flow. Using the same trick as I used for detecting the delegates, can I find the origin of TITAN-related transactions?
-
Delegates can easily avoid this by using relays in such a way that the delegate is connected only to relays. Relays will not forward invalid or duplicate transactions.
Valid transactions are OK provided they have sufficient trx fee. It is OK to flood the network with transactions. You'll pay the price.
However your method will reliably filter out unprepared delegates. That is a good exercise I was meaning to do for a long time.
So my attack was deflected. Ok, the next one:
Attack scenario
I flood the network with sybil nodes and start monitoring transaction flow. Using the same trick as I used for detecting the delegates, can I find the origin of TITAN-related transactions?
Dont be so quick to mark the attack as deflected. I think 80%+ of the delegates will fall for it. It should be attempted. It might show flaws that we've never thought about.
Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.
-
Similar method to your next attack scenario is used to identify TOR nodes. It might work provided you have enough nodes and/or the "victim" is connected to one of them.
Ok, but it's easily fixable with an anti-Sybil solution. Just add it to the schedule if TITAN is vulnerable to such kind of attack.
Edit: Actually anti-Sybil protects against a lot of attacks, I need some time to devise something that doesn't use a Sybil attack as an opening move.
-
What is an "anti-sybil solution"? I know what sybil attacks are.
-
What is an "anti-sybil solution"? I know what sybil attacks are.
It would be difficult (or restrictive for end users) to implement such solution for bitshares.
I'm not sure if there are plans for such anti-sybil solution. I cant remember it being discussed at all.
-
What is an "anti-sybil solution"? I know what sybil attacks are.
Anti-sybil solution is something that mitigates sybil attacks.
-
Right. Can you give an example?
EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'
-
It would be difficult (or restrictive for end users) to implement such solution for bitshares.
This world is not ideal, it's full of trade-offs...
-
Right. Can you give an example?
EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'
I can't give an example. I know 2 effective solutions, but one of them can't be used in BitShares and another is a proprietary tech of our company.
-
Right. Can you give an example?
EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'
I can't give an example. I know 2 effective solutions, but one of them can't be used in BitShares and another is a proprietary tech of our company.
And what is that company ? You can PM me the name...
-
Right. Can you give an example?
EDIT: Reminds me when you look up 'beautiful' and the definition is 'full of beauty'
I can't give an example. I know 2 effective solutions, but one of them can't be used in BitShares and another is a proprietary tech of our company.
If this is the case, maybe you shouldn't dismiss using a sybil attack as your opening move ;)
-
And what is that company ? You can PM me the name...
The same company that is developing the hardware that supports blockchain tech.
-
Am I sensing a product promotion opportunity here?
-
And what is that company ? You can PM me the name...
The same company that is developing the hardware that supports blockchain tech.
Is any of the following true for your proprietary solution:
Your proprietary solution require users to purchase your hardware.
Your proprietary solution decreases privacy .
Your proprietary solution decreases usability .
Your proprietary solution involves POW .
-
Am I sensing a product promotion opportunity here?
I don't promote our product. We have already sold this tech to one of your competitors and not interested in selling it to someone else. :)
-
I don't promote our product. We have already sold this tech to one of your competitors and not interested in selling it to someone else. :)
Who is the competitor and what is your coy name?
-
Your proprietary solution require users to purchase your hardware.
This is the first case.
Your proprietary solution involves POW .
This is the second one.
-
Who is the competitor and what is your coy name?
The both are NDA'ed :)
-
Who is the competitor and what is your coy name?
The both are NDA'ed :)
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.
-
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.
Right. Let's assume that Sybil attack is mitigated and look for other weak spots.
-
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.
Right. Let's assume that Sybil attack is mitigated and look for other weak spots.
Hold on. Can that be mitigated by making changes to the software codes? I think something like DNS with reverse lookup and certificates can help.
-
Hopefully the fact that our competitors are still pursuing POW (and proprietary, at that) gives us time to clean up our ui and get marketing caught up.
-
Hopefully the fact that our competitors are still pursuing POW (and proprietary, at that) gives us time to clean up our ui and get marketing caught up.
We only have one competitor, ethereum.
And they're not dicking around.
-
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.
Right. Let's assume that Sybil attack is mitigated and look for other weak spots.
Hold on. Can that be mitigated by making changes to the software codes? I think something like DNS with reverse lookup and certificates can help.
Hold on! Where is the privacy ? Dont touch that.
-
Hold on. Can that be mitigated by making changes to the software codes?
Yes.
-
They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.
Right. Let's assume that Sybil attack is mitigated and look for other weak spots.
Hold on. Can that be mitigated by making changes to the software codes? I think something like DNS with reverse lookup and certificates can help.
Hold on! Where is the privacy ? Dont touch that.
That is something we need to work out as part of the solution.
-
A double-spending attack has come to my mind but it requires a sybil attack to conduct an eclipse attack... Heh, without ability to control the communications it's quite hard to do something hostile.
-
A double-spending attack has come to my mind but it requires a sybil attack to conduct an eclipse attack... Heh, without ability to control the communications it's quite hard to do something hostile.
Isn't that the whole point of consensus mechanics to solve the Two-Generals problem?
-
Isn't that the whole point of consensus mechanics to solve the Two-Generals problem?
Two Generals problem is unsolvable IIRC.
-
Hopefully the fact that our competitors are still pursuing POW (and proprietary, at that) gives us time to clean up our ui and get marketing caught up.
We only have one competitor, ethereum.
And they're not dicking around.
This is most certainly an ethereum thing. They've long had plans to start out with a proprietary hardware POW solution, then possibly shift into POS later.
-
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them. If we hit the delegates in this way, the ones that are lax will need to step it up!
New idea: Sybil attack all the paid delegates in particular. The ones that have lax security will miss blocks and not get paid. Serves them right! :)
-
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them. If we hit the delegates in this way, the ones that are lax will need to step it up!
New idea: Sybil attack all the paid delegates in particular. The ones that have lax security will miss blocks and not get paid. Serves them right! :)
Forced compliance...
A little extreme isn't it?
-
Does http://wiki.bitshares.org/index.php/BitShares/Market_Peg contain actual info?
-
Does http://wiki.bitshares.org/index.php/BitShares/Market_Peg contain actual info?
I do not believe that is still accurate. A lot of the wiki is very outdated.
Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "
Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work. Specifically, there was no reason for the peg to hold, the price could simply go to 0.
The solution to this was to implement:
* Feeds. Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days. In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price. This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait.
* Margin calls enforced by the blockchain. In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call. This liquidates the asset and gives the fair value of the asset to the holder (in BTS).
This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month.
The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover. (A flash crash with no bounce back).
In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange. The market cap of the aset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will nto have lost their money, they will have sold them for equivalent value in BTS.
-
I think the sybil attacks are actually the most promising and we should focus on that.
Solutions do exist as Bytemaster posted but I worry that too few delegates are using them. If we hit the delegates in this way, the ones that are lax will need to step it up!
New idea: Sybil attack all the paid delegates in particular. The ones that have lax security will miss blocks and not get paid. Serves them right! :)
Forced compliance...
A little extreme isn't it?
More like Forced "do not be vulnerable to attacks that could disrupt the blockchain". It is critical that our delegates are secure.
-
I do not believe that is still accurate. A lot of the wiki is very outdated.
Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "
Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work. Specifically, there was no reason for the peg to hold, the price could simply go to 0.
The solution to this was to implement:
* Feeds. Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days. In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price. This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait.
* Margin calls enforced by the blockchain. In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call. This liquidates the asset and gives the fair value of the asset to the holder (in BTS).
This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month.
The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover. (A flash crash with no bounce back).
In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange. The market cap of the aset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will nto have lost their money, they will have sold them for equivalent value in BTS.
Thank you. Looks like this can't be attacked at the technical level (assuming that channels the delegates get info about USD price from do not belong to BitShares protocol).
-
I do not believe that is still accurate. A lot of the wiki is very outdated.
Specifically, I think this part is wrong:
" This happens by behavioural confirmation - all traders in the blockchain expect BitUSD to peg to the dollar, which leads them to trade in ways that reaffirm that expectation. If traders start to see Bitshares rising in value relative to dollars, this will result in lower bids being put in for BitUSD because of the expectation of seeing lower asks from the shorts. "
Back in august/september time frame, this was discussed a lot and it was pretty clear to many that this plan would not work. Specifically, there was no reason for the peg to hold, the price could simply go to 0.
The solution to this was to implement:
* Feeds. Delegates provide feeds to the system, telling the blockchain how much BTS each asset is worth.
* Forced covering after 30 days. In order to prevent the asset price from going to 0, shorts (who created the asset), are forced to cover after 30 days, at the feed price. This assures that a bitasset holder will get fair value for their bitasset with a 30 day or less wait.
* Margin calls enforced by the blockchain. In order to ensure that sufficient collateral always exists in order to pay asset holders, any time a short has insufficient collateral to cover 200% of the value of the assets, they are issued an automatic margin call. This liquidates the asset and gives the fair value of the asset to the holder (in BTS).
This ensures that bitAsset holders can always receive fair value of the asset if they are willing to wait up to 1 month.
The only way this fails is an extreme black swan event which causes the price of BTS to fall 66% in hours, and doesnt recover. (A flash crash with no bounce back).
In the case where demand for a bitAsset dries up and no one wants it at all anymore, all of the asset will end up being liquidated within 30 days, and the holders will have been given fair value worth of BTS in exchange. The market cap of the asset (bitUSD or whatever) will then be 0, with 0 of the asset existing, but holders of the asset will not have lost their money, they will have sold them for equivalent value in BTS.
Thank you. Looks like this can't be attacked at the technical level (assuming that channels the delegates get info about USD price from do not belong to BitShares protocol).
The delegates all set up their own price feeds and are supposed to use lots of different sources. They get their info elsewhere and then broadcast the informaiton to the Bitshares network when they create blocks. (They don't do it every block, just sometimes. For many they do it once a day or once an hour. Some delegates dont provide feeds, but this is a problem that should be worked on. As Bitshares grows, delegates would be pressured more to provide feeds. Currently most of them do.
The Median price feed is used. (It doesnt average, so corrupting 1 delegate and posting a bogus price wont do anything).
I think that if you corrupted 51 delegates that you could launch some sort of attack on this system, but I dont think thats surprising. 51% lets you attack every coin. And it would be really obvious to everyone what was happening.
-
Is there anyone here who can edit the wiki and change that page?
I dont like that it gives an outdated explanation of the peg which we all discussed and showed to be flawed. People could read that, realize that it doesnt work, and avoid bitshares as a result, even though we have already implemented a much better system months ago.
-
Paging @gamey
-
Is there anyone here who can edit the wiki and change that page?
I dont like that it gives an outdated explanation of the peg which we all discussed and showed to be flawed. People could read that, realize that it doesnt work, and avoid bitshares as a result, even though we have already implemented a much better system months ago.
There are several admins who can create accounts. If you are saying you wouldn't mind contributing to it a bit i'll login and create an account for you, Ander. Looks like that page in particular has been broken for some time.
-
Sure, make me an account. Thanks!
-
Sure, make me an account. Thanks!
Moooossssst excellent. The community thanks you and I thank you !
-
We have already sold this tech to one of your competitors :)
this? https://nxtforum.org/unity/supernet-funds-request-authorization-thread-official/msg155144/#msg155144
-
We have already sold this tech to one of your competitors :)
this? https://nxtforum.org/unity/supernet-funds-request-authorization-thread-official/msg155144/#msg155144
Since when did Supernet become a competitor? How is James going to use the trinary product?
-
Lol idk that was a question. Dont take my word for it.
-
Since when did Supernet become a competitor? How is James going to use the trinary product?
They are developing features similar to ones in BitShares.
-
So that deal was the one you talked about right cfb?
-
Since when did Supernet become a competitor? How is James going to use the trinary product?
They are developing features similar to ones in BitShares.
@paging BM.
What are the features they are developing? DPOS? inbuilt wallet exchange? bitassets? Why not collaborate with BitShares and not re-invent the wheel?
-
@paging BM.
What are the features they are developing? DPOS? inbuilt wallet exchange? bitassets? Why not collaborate with BitShares and not re-invent the wheel?
All the features can't be fit into a single system. At one point the devs will become the bottleneck.
-
Since when did Supernet become a competitor? How is James going to use the trinary product?
They are developing features similar to ones in BitShares.
@paging BM.
What are the features they are developing? DPOS? inbuilt wallet exchange? bitassets? Why not collaborate with BitShares and not re-invent the wheel?
I actually think it is kind of cool to see they are trying to reinvent the wheel. I also think it is awesome that supernet is reaching out to other altcoin communities to pool resources. I think bitshares should take this as an example of what we SHOULD be doing using our superior technology because if we don't, other projects will. If this concerns people at all...it kind of should.
However, with that said, the "attack on BitShares" is only an attack on the blockchain and tech...as long as the people stay and the devs fix any flaws found...we end up stronger in the end. To that end I say enjoy the ride!
-
A double-spending attack has come to my mind but it requires a sybil attack to conduct an eclipse attack... Heh, without ability to control the communications it's quite hard to do something hostile.
Assuming sybil attack is possible, is an eclipse attack feasible?
-
Assuming sybil attack is possible, is an eclipse attack feasible?
Yes. Most of "DDoS service" packets include "100% efficiency or money back" condition. So seed nodes won't help much.
-
Sure, make me an account. Thanks!
Moooossssst excellent. The community thanks you and I thank you !
I probably wont be able to get to it for a couple days, but I'll try to update this weekend.