BitShares XT - Security against Market Manipulation FIND ATTACKS FOR TIPS

[bitbadger]

In a fully peer to peer network it is easy to detect nodes that do not relay transactions when you send them.  These non-relaying nodes can be independently detected and disconnected in a decentralized manner.

How so?  Could they not just spoof that they are passing on transactions?  From the above, am I to understand that the standard behavior is to mirror all transactions back to the sender, as well as relaying them on to other nodes?  What if they just send it back to you so you think they're relaying, but they do not forward it on to other nodes?  And again, what if they selectively relay?  How could that be detected?  Especially if they do so in a somewhat balanced but stochastic manner, e.g. they relay 100% of downward bids but only 25% of upward bids, in an effort to drive the price down?  While at the same time a whale starts blowing holes through the floor, and ALL of those bids are passed on?

Furthermore, you say "easy to detect", "independently detected and disconnected"... so is this code already implemented?

I am not terribly concerned about such an attack because the solution is very simple... add just one or two trusted peers to the majority of nodes and you can be sure you are not isolated and missing transactions.

And what happens when those "one or two trusted peers" are knocked off the network due to DOS attacks on all of the publicized/biggest nodes?  All of a sudden, all of your information is coming from who knows what source.

Furthermore, if you are fully isolated and missing transactions then that means your blockchain would fall behind unless the attacker owned enough stake to mine an alternative chain with fewer transactions.  Note that including transactions is critical to growing the blockchain.

Could they not pass on all blocks that are mined, but drop transactions?

I know I keep bringing up DOS attacks.  This is because I really think that they will be at the heart of any attack on the network.  They can't do anything bad on their own, but they can create the conditions where bad things can be done more easily. 

Plain bandwidth DOS (even if the connections are all blocked by your router/firewall, if you have a consumer-level connection then your upstream line can be saturated VERY easily) as well as targeted DOS, selectively connecting to the open ports for the BTS network, spoofing new peer requests (from unknown IP's), spoofing transactions (from already connected peers), spoofing blocks (same)...

If your node is passed 100 false blocks all of a sudden from a peer, as if they were all mined in quick succession, how long will it take the client to process and discard them as false?  What about 1000 blocks?  Is there a rate limiter, a sanity check on this? 

Same with transactions.... what if you're used to getting 5-10 orders propagated per second, then all of a sudden you're getting 1000 per second?  Will the daemon be able to keep up?  How are the orders checked?  Presumably each one is verified against the known public key for the address that generated it, right?  Is the account balance also checked versus the blockchain?  How many milliseconds does it take to check each one?  Are they propagated immediately, or only after being checked?  (I.e., are you also now DOS'ing your peers?) How many will it take to bog down the CPU or fill up the RAM of a standard PC? 

If you're connected to 12 peers, and all of a sudden 6 of them start slamming you with false orders, how long does it take before you stop taking more in? 

Hell, they don't even have to be false.  They just have to be spammy.  Valid orders for tiny amounts.  Even if there is a minimum transaction size or a fee implemented and those orders are rejected, they still look valid on their face, and will have to be inspected before they are discarded.  This will take some time.

[bytemaster]

If every node you connected to was able to prove its stake in the network then you could make sure you connected to enough nodes that were not giant botnets.

This is true... which I guess brings up the question, is stake broadcast?  Or rather, are ID's broadcast, since stake is known from the blockchain?  Or rather.... I guess all that would need to happen would be for IP's to be printed on transactions, and your client could preferentially connect to the nodes with the highest stake, since you know stake already, and you can look for recent transactions involving large-stake ID's, and connect to those IP's.  Of course, then we have a problem where high-stake nodes could get overloaded with connections.

Eh.  I guess too many of my questions involve implementation details of which I am not aware.  Guess I need to dig into the code.

But I guess I would ask: are you not concerned about what botnets could do to the network?  Is the problem already solved, or do you just think it unlikely?  Also, while I think the testing phase for BitShares X is a wise idea, the problem is that if somebody has a real exploit, they have no incentive to use it during the testing phase when they know that a rollback is possible.

The initial network will not be fully peer to peer the network operator (not us) will be able to halt all trading if necessary and wait for a fix.   This also means that all clients will be connecting to trusted nodes spread across the world and know for certain their transactions will make it through.

In a fully peer to peer network it is easy to detect nodes that do not relay transactions when you send them.  These non-relaying nodes can be independently detected and disconnected in a decentralized manner.    I am not terribly concerned about such an attack because the solution is very simple... add just one or two trusted peers to the majority of nodes and you can be sure you are not isolated and missing transactions. 

Furthermore, if you are fully isolated and missing transactions then that means your blockchain would fall behind unless the attacker owned enough stake to mine an alternative chain with fewer transactions.  Note that including transactions is critical to growing the blockchain. 

[bitbadger]

If every node you connected to was able to prove its stake in the network then you could make sure you connected to enough nodes that were not giant botnets.

This is true... which I guess brings up the question, is stake broadcast?  Or rather, are ID's broadcast, since stake is known from the blockchain?  Or rather.... I guess all that would need to happen would be for IP's to be printed on transactions, and your client could preferentially connect to the nodes with the highest stake, since you know stake already, and you can look for recent transactions involving large-stake ID's, and connect to those IP's.  Of course, then we have a problem where high-stake nodes could get overloaded with connections.

Eh.  I guess too many of my questions involve implementation details of which I am not aware.  Guess I need to dig into the code.

But I guess I would ask: are you not concerned about what botnets could do to the network?  Is the problem already solved, or do you just think it unlikely?  Also, while I think the testing phase for BitShares X is a wise idea, the problem is that if somebody has a real exploit, they have no incentive to use it during the testing phase when they know that a rollback is possible.

[bytemaster]

If every node you connected to was able to prove its stake in the network then you could make sure you connected to enough nodes that were not giant botnets.

[bitbadger]

Rolling back a block does more than just unwind the market, it unwinds all transfers.  Having to unwind the network is reacting too late...

I agree, but reacting late is what we all do when we find out that we're fallible.  We simply don't believe it until proven to be so.

It is kind of like the US Constitution containing provisions for it to be amended.  The Founders realized that the system would have unforeseen problems, and that the system therefore needed to have an internal process for changing itself.  Not a good idea to rely on revolutions acting outside the system; better for the system to allow change within itself.

--------

As a side note: any comments on the network security problem?  The network is only as secure as the least secure critical node (and there will be critical nodes).  Since we have no way of privileging critical nodes, the network is only as secure as the least secure node.  Yes, presumably people will add hardened networks, diversify their network locations, etc. over time.  But it will take a while before it reaches that point.

Until that time, maybe there won't be any attacks like I'm outlining, because there won't be enough value in the system to make it worthwhile.  And once the system does reach that valuable level, all critical nodes will pay to provide their own security.  Still, the threat exists, and the threat is not just to individual nodes, but to the network as a whole; especially for pegged assets such as BitUSD.  The thought that liquidity could be forced off the network is a scary one.  I think that some level of IP obfuscation would be a good idea.  Maybe not initially, and maybe not in every DAC; but eventually, and in at least some DACs.

--------

As another thought, what if somebody seeded the network with bad nodes?  Create a million node botnet, and have these nodes simply drop all transactions instead of propagating them correctly.  Or, perhaps worse, propagate certain transactions while dropping others entirely.  If these bad nodes constituted a majority of the network (not the stake, but the network) then they could manipulate things fairly easily.  Of course these nodes would have a latent period of acting normally, until the owner flips the switch and starts dropping transactions in order to manipulate the market.

Perhaps an explicit network connection mapping mechanism could be tied to stake?  Sort of a matchmaking service for nodes to decide who gets to peer to whom.  Presumably a botnet attack with millions of nodes would have very little, or no, stake per node.  So make it so that those nodes can't connect directly to nodes with a large amount of stake; or only a limited number of them can.... for example purposes, say nodes can have stake of value from 0 to 10.  Say that a node with stake 10 has 10 allowed connections: 3 allotted to stakes in the range 6-10, 3 allotted to 3-5, and 4 allotted to 0-2.  So a node with stake 10 can never be "surrounded" with only nodes of stake 0, where all transactions initiated by the stake-10 node must be propagated through stake-0 nodes in order to reach the rest of the network.  So if someone created a million node botnet, all of those nodes would be able to join the network, but they would all be on the periphery of the network, and they could never penetrate deeply into the interstices where they could interrupt the communication from one critical node to another.

Of course, a node with high stake could still attempt something like this, but the good thing about this plan is that stake must be concentrated in order to reach the inner parts of the network, while large numbers of nodes are needed to carry out a dropped-transaction attack.  So the larger your number of nodes, the lower the stake per node, and the less ability to carry out an attack.

TL;DR: A proposal for the network to allow peers based on trust, where trust is based on stake, in order to prevent attacks by numerous nodes not propagating transactions.

[mf-tzo]

Markus, you understand correctly about LCH. You have to cover your margin call the next morning for cob the previous day otherwise you get liquidated your position (of course you can have a credit line to avoid liquidation). The reason for this is because the index (and I am talking i.e specifically for the Dry Bulk indexes in Baltic exchange) is settled every day late in the afternoon where banks are closed in Europe. I guess that this doesn't apply here.

I guess in the future you might do the same with the BPI index (coindesk) which gives you the settlement price of Bitcoin. However this should be acceptable for all the bitcoin users and I don't think this is the case now. Until the bitcoin market matures and becomes more liquid this might cause problems. If settlement was based on Coindesk's BPI I expect a lot of arbitrage would take place among the different exchanges. And when there is arbitrage and the law of one price doesn't apply there is no efficient market.

[bytemaster]

Rolling back a block does more than just unwind the market, it unwinds all transfers.  Having to unwind the network is reacting too late...

[bitbadger]

Not sure about part 1 but built-in rollback mechanics are bad. Either a chain fails or it doesn't. If it does, there will quickly become a new consensus chain that people will be forced to deal with. A DAC isn't just the blockchain, it's the network that looks after it. Look at bitcoin fork post-mortem for an example of how it can work.

Yes, but that gets away from the decentralization aspect if people have to go to some forum to figure out what they want to do in order to reach consensus.  Because then that forum becomes a centralized part, a power player.  If it is hacked or compromised or simply unavailable, what are people going to do?  What if this webserver is rooted and some nefarious person starts posting as bytemaster, telling people to download a new client that fixes X problem?  It all comes down to putting trust into some central authority, and that is what we are explicitly trying to move away from here, right?

And then how is consensus measured?  I guess you could say people downloading the new client that fixes the problem, and picking a certain fork or whatever, is consensus... but then how does the Proof of Stake work?  What if my Stake is on the wrong fork?  I was trying to think of a way to use Stake as a decentralized voting/consensus mechanism, within the system itself, not relying on sidebands.

[toast]

Not sure about part 1 but built-in rollback mechanics are bad. Either a chain fails or it doesn't. If it does, there will quickly become a new consensus chain that people will be forced to deal with. A DAC isn't just the blockchain, it's the network that looks after it. Look at bitcoin fork post-mortem for an example of how it can work.

[bitbadger]

DOS attacks / knocking nodes off the network

I am still concerned with DOS attacks on nodes.  We will have some number of nodes making automated trades all the time and acting as market-makers.  Their IP's will presumably be visible.  Those IP's can be DOS attacked with a high probability of success.  Professionally hosted servers with fast Ethernet speeds and robust firewalls can resist DOS, but most consumer-level nodes will not have this degree of protection.  I would feel wary of placing many orders knowing that I could be knocked off the network indefinitely and without notice.  Even if there are several hundred nodes acting as market makers, if a good chunk of them can be blocked from the network, then the depth of the market will drop dramatically.

IMO this is the greatest threat to the exchanges.  Wall Street exchanges have hardened, direct connections between nodes -- no connection to the outside Internet, or to any untrusted/unbonded entities.  Every node on those networks has a name, a face, and a federal EIN.  They can screw up and place wrong orders, but those orders can be tracked and cancelled if necessary by a central authority.

BTS XT has no limits to the number of connected nodes.  No node can ever be banned, because it can just change addresses and show up again anonymously.  Hundreds, thousands, even millions of nodes (botnets) can all connect and appear to be acting independently when they are actually under unified control.

I am unsure what can be done of this.  TOR-like obfuscation of IP's might be a good start.  This essentially consists of a routing table.  Each node can be connected to a maximum number of other nodes.  Base it on a logarithmic function of the total number of nodes in the network.  So if there are 20 nodes, each node can be connected to 5 other nodes.  If there are 20,000 nodes, each node can be connected to 50 other nodes.  Each node maintains a list of all other nodes, which are denoted by random addresses.  Node A knows that it can access Node B through IP address 9.9.9.9, but Node A has no idea whether Node B actually resides at 9.9.9.9, or if it is actually 20 levels of indirection behind 9.9.9.9. 

This way, all IP addresses are obscured; there may be a market maker on the network named BiaJ8asfl9, but it would take a lot of work to figure out its actual IP address.  It would not be impossible, since I could simply create 1 million new nodes, and have them all connect to the maximum number of nodes, and through a process of elimination and network mapping, figure out the direct IP address for node BiaJ8asfl9.  But this would be a very difficult undertaking.

Proposed mechanism for rollbacks

On a semi-related note, I also wonder about rollbacks, and the possibility for consensus-based rollbacks.  If a major attack on a fatal vulnerability starts in Block 21839, then a consensus of stakeholders ought to be able to agree to roll back to Block 21838 after the vulnerability has been fixed.  I propose that a consensus could be created without a central authority having anything to do with it.  If such an event were to happen, surely a large proportion of the network would be aware of it.  They would independently create rollback requests to Block 21838.  After some fixed proportion of stakeholders (25%? 50%?) have created these requests (which are put into the blockchain) then the rollback requests start showing up in people's wallets/GUI/whatchamacallits: "Do you support rolling back to Block 21838?" with a Yes or No vote (voting "Yes" adds a new rollback request for this stakeholder).  This way, consensus can be created, but it requires a large number of stakeholders independently creating the initial requests, without a central authority having to initiate or approve of anything.  Each stakeholder can only have one rollback request active at a time; they can be withdrawn at any point, at which point a "cancel" appears in the blockchain.  Once a supermajority is reached (75%? 90%?  90% of all stake active within the past week?) then the rollback occurs immediately and irrevocably.  The blockchain is simply truncated at the chosen block.

[Markus]

I am a bit sceptical about BitCryptos (BitBTC, BitLTC etc.) catching on.

What is the incentive of being long in such an asset? It is already virtual with all associated benefits (speedy transfer, pseudonymity, easy storage, ...). It is not like with BitUSD or BitGold that you have any advantages over the original.

This is why I suggest more fiat. At least CNY and EUR.

Why would you not want to be able to short your competitors while maintaining and accumulating more stake in your superior company. If bitshares is successful those that short BitCryptos win the most.

I know shorting is new and useful, but to be short you need a counter-party being long. What are the advantages of holding BitBTC vs. holding BTC?

[clout]

I am a bit sceptical about BitCryptos (BitBTC, BitLTC etc.) catching on.

What is the incentive of being long in such an asset? It is already virtual with all associated benefits (speedy transfer, pseudonymity, easy storage, ...). It is not like with BitUSD or BitGold that you have any advantages over the original.

This is why I suggest more fiat. At least CNY and EUR.

Why would you not want to be able to short your competitors while maintaining and accumulating more stake in your superior company. If bitshares is successful those that short BitCryptos win the most.

[pariah99]

I am a bit sceptical about BitCryptos (BitBTC, BitLTC etc.) catching on.

What is the incentive of being long in such an asset? It is already virtual with all associated benefits (speedy transfer, pseudonymity, easy storage, ...). It is not like with BitUSD or BitGold that you have any advantages over the original.

This is why I suggest more fiat. At least CNY and EUR.

There's already a large infrastructure supporting the BitCoin ecosystem, same as with the US Dollar.

BTS-X is a pilot run and it might have some kinks to iron out - Better to fix them while there's a limited set of assets rather than complicate things with a whole slew of them.

[Markus]

I am a bit sceptical about BitCryptos (BitBTC, BitLTC etc.) catching on.

What is the incentive of being long in such an asset? It is already virtual with all associated benefits (speedy transfer, pseudonymity, easy storage, ...). It is not like with BitUSD or BitGold that you have any advantages over the original.

This is why I suggest more fiat. At least CNY and EUR.

[toast]

That is why it is critical to keep BitUSD, because both BitUSD and BitBTC will have volume that interacts with real BTC and USD. Trading gold for BitGold without converting to one of the two other assets IRL will probably not happen for a while.

I support XTS/USD/BTC/GLD