Over the past week many people have identified certain attacks that we must guard against in the initial chain.   The theory behind BitShares XT works very well in a large established network, but early on in the life of a network things break down due to low market depth.    A few simple attacks have come to my attention that must be resolved and I will be posting them each in their own thread.  I would like to use this thread to discuss potential attacks and if an attack warrants in depth discussion I will spawn a new thread to discuss it.

I am not going to place a specific bounty price for finding attacks, lets just say that if you bring something to my attention that makes me realize something new that I will tip very generously up to hundreds of PTS.

This thread is motivated by the discovery of two attacks for which I have found solutions which will impact BitShares XTs rules:

Attack 1)  The SIDS Attack   (Sudden Instant Derivative Sack)

In this attack any user who is around when the blockchain is first launched can issue themselves $1 billion BitUSD as a long position with a short position of $1 billion BitUSD backed by 1 BTS.   It doesn't matter what the future consensus is, the short position will be blown out in a massive way and leave billions of BitUSD laying around with no backing. 

The solution to the SIDS Attack is two fold: 

   a) no market trading will be allowed for the first N days to allow enough people time to enter bids and asks that arrive at market consensus.
   b) no market trading will be allowed anytime either side of the order book has a depth below D% of the share supply.

This rule effectively states that for blockchain based trading to occur in an automated way there must be a quorum of shareholders agreeing on the price.  This does not prevent private parties from transferring BitUSD or BTS to other users or arranging manual trades.  It simply prevents any manipulation of the price that could result in margin calls at unrealistic prices.

The values for N and D are subject to debate, but my gut feeling is that N should be 14 days and D should be 5%

Attack 2)  The SlingShot Attack  (Other names welcome)

   In this attack, the attacker will place a large short order close to 2x above the current ask.  Under normal conditions this order would never be filled.   Then the attacker starts buying to push the price up until he triggers a short squeeze.   The short squeeze starts a chain reaction that pushes the price clear up into the attackers short position.  Then the price falls back to where it should and the attacker covers their position with a 50% gain.  Whether this attack is profitable or not depends upon how big of a short squeeze the attacker can trigger and how little is required to kick off the squeeze.   

I have been thinking long and hard about the SlingShot Attack and have concluded that the only solution is to increase margin requirements.  As it exists today, if someone wants to short 1 BitUSD the most they risk is 1 BitUSD.   On a traditional exchange, if you want to short something your potential losses are infinite because if you run out of margin then they can come after your savings, your house, and your future income.    The SlingShot Attack is much harder if the margin requirements make the probability of a short squeeze much lower.   

Lets assume a very conservative amount of margin, 10x.   To perform the SlingShot attack would require pushing the price up 9x and would reduce the attackers gain from a maximum of 50% to a maximum of 5%.    If you then combine this increase in margin requirements with the automatic market freeze anytime the depth fell below the required threshold and you will be unlikely to walk the book enough to trigger a short squeeze without suspending trading.

   What is the impact of requiring a larger margin for short positions?  People will still go short, but the amount of leverage they can apply will be reduced significantly.  BitUSD will still be created and thus will still trade.  Instead of the marketcap of BTS being 2x the value of the trading BitAssets it would now be at least 10x the value of the BitAssets traded.    Thus increasing margin requirements should only limit the ability to go short and have little influence on the price people are willing to go short.  Shorts will feel much more secure knowing that other shorts are less likely to end up in a squeeze which will balance out with the added risk of losing up to 10x the amount you shorted.   

    Based upon these two attacks and the need for significant market depth before the chain can be 'secure' I am starting to conclude that market depth is more important than transaction volume in limiting the number of BitAssets per chain.   For this reason I am thinking that the BitShares XT network should have only 2 BitAssets (Gold and Bitcoin).   We want to focus the trading efforts and market depth on two assets rather than spreading the network thin.   Once we understand the security implications future chains are likely to start with a larger user base, deeper markets, higher initial valuation, and thus able to support more assets securely.

    Please let me know of any other attack ideas you can come up with and what your thoughts are on these rule refinements?



 

I am sorry for bring ups an old subjest but I just got around to read this. In order to short there must be inventory to borrow. Typically this inventory is held by institutions in the traditional market sense and lend this inventory to short sellers on margin. How are you accounting for inventory since there are no "institutions" holding  inventory/float?  Are you going to allow users the ability to lend out there own shares in a public pool? Are you going to show the amount of short inventory or rather the amount allowed to be borrowed to short? 

maybe you have this in a paper?
 

This may not be the right place for the topic but i wanted to discuss it anyway.  please feel free to move it where you believe it needs t go.

Questions and possible testing requirements of the network.

• Delegate are required to maintain a mimimum number of connections to make blocks.  What keeps a delegate from running multiple delegates maintaining the min connections?  If the current min connection is 5, and a delegate is running 5+ each with "hard added nodes", then these effectively can produce blocks on their own.  What happens in the event this happens
• What happens if a  multi-delegate maintain min connection but blocks IPs of other delegates.
• How do you monitor that delegates are not actively participating in blocking other delegates.
• It seems to me, that to be a delegate, we would want ones the have the most active connections and therefore providing the most network connectivity since this is the most important feature of blockchain creation. It seems to me that delegates should be maintaining at least 100 connections. I find it strange that we can't get 100 connections.  IS anyone else getting even close to that?

[li] I think it would be a good idea for there to be a reporting mechanism for delegates to show active connections with peers.  this would allow the BTX to visually network connectivity maps. Who know what useful information this would provide.


[/li][/list]

I have the rpc server started but I cannot connect using python and requests....can someone tell me why I am getting this error.  I have no problems conneting python to http server..


ConnectionError: HTTPConnectionPool(host='localhost', port=18332): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 10061] No connection could be made because the target machine actively refused it)

config.json rpc info

"rpc": {
    "enable": true,
    "rpc_user": "user",
    "rpc_password": "1234",
    "rpc_endpoint": "localhost:18832",
    "httpd_endpoint": "localhost:8801",
    "htdocs": "./htdocs"



python code snippet....

serverURL = 'http://' + rpc_user + ':' + rpc_password + '@localhost:' + str(rpcPort)
headers = {'content-type': 'application/json'}
payload = json.dumps({"method": 'get_info', "jsonrpc": "2.0"})
response = requests.get(serverURL, headers=headers, data=payload)
print(response.json()['result'])

When can we import our real Bitshares wallet so that we can test its functionality?

Metronome or metronode

Chronicle node

So far, I'd keep it simple like timestamp or clock node.

Quote from: GaltReport on March 19, 2014, 09:29:09 pm

As you can see I am a Newbie!! 

I gather from the previous comments that one can't download to help test Keyhotee at this point due to lack of a Keyhotee ID?

You don't need a Keyhotee ID to help test it, you can create an identity with just a public key (not tied to a KH ID) and use the public key as your mailing address for now. That's actually how everyone tests it right now.

I cant seem to create a public key without a Keyhotee ID.   Can anyone tell me how to do that?  It does not generate a public key until I type in something in the Keyhotee ID field.  Please advise. thanks

I have attempted to compile the code.  However, I get the following errors under cygwin 64..
 
make -f makefile.mingw64
yasm -f win64 -D WINABI -o obj/sha512_avx.o_asm intel/sha512_avx.asm
yasm -f win64 -D WINABI -o obj/sha512_sse4.o_asm intel/sha512_sse4.asm
g++ -c -O2 -march=athlon64 -mmmx -msse -msse2   -fpermissive -o obj/sha512.o_amd                               sha512.c
g++ -c -O1 -march=athlon64 -mmmx -msse -msse2   -fpermissive -o obj/sph_sha2.o_a                              md sph_sha2.c
g++ -c -O1 -march=athlon64 -mmmx -msse -msse2   -fpermissive -o obj/sph_sha2big.                              o_amd sph_sha2big.c
g++ -c -O2 -march=athlon64 -mmmx -msse -msse2  -mthreads -w -Wall -Wextra -Wform                              at -Wformat-security -Wno-unused-parameter  -DWIN32 -D_WINDOWS -DBOOST_THREAD_US                              E_LIB -DBOOST_SPIRIT_THREADSAFE  -I"/home/jng/cudapts-master/cudapts-master" -I"                              /usr/local/include" -o obj/main_poolminer.o_amd main_poolminer.cpp
main_poolminer.cpp:18:25: fatal error: sys/syscall.h: No such file or directory
 #include <sys/syscall.h>
                         ^
compilation terminated.
makefile.mingw64:66: recipe for target 'obj/main_poolminer.o_amd' failed
make: *** [obj/main_poolminer.o_amd] Error 1

i dont see a file in the github for syscall.h...also, how do I find the boost suffix?,  I am almost there, so your help is appreciated.