A few attack ideas, by no means an exhaustive list.
Ultimately, all cryptocurrency
*or digital shares, or whatever you want to call strings of numbers which are used to access something of value attacks come down to double-spend. The holder of a secret, whether they came by that secret legitimately or not, attempts to extract value from that secret when they have no right to. Legitimate owners of a secret should only use it to assign its value once. Illegitimate possessors of a secret can attempt to assign the value of that secret before the legitimate owner does thereby stealing it from the legitimate owner.
The various other attacks listed are either a means to enable double spend, increase net yield of double spend return, or griefing to diminish the value of an issue for whatever reasons.
In Accumulation attack, a bad actor slowly collects copies of secret keys
*obtained by any number of methods - note that interception of assignment transaction traffic does not help because secret keys are never exposed in assignment transactions, only proven to be in the possession of the user of the secret key. of small values. Being of small value, these keys are sometimes less carefully protected by their owners. By collecting the copies slowly, in small increments, potentially spread out in different locations, suspicion is harder to place. Nobody knows that their secrets have been copied, so they don't know that they are at risk of losing those secrets' value.
Short expiration periods, and/or frequent trading for new shares can be effective deterrents against an accumulation attack. High recording and assignment costs run counter to this defense, but a good balance should be possible.
Simple, brute force overloading of a server with meaningless traffic, effectively blocking legitimate server operations. The more creative uses of DoS attacks attempt to enable double-spend by creating "islands of processing" where two recording servers operate independently and the attacker records the same key on the same blockchain on both servers before they reconnect. Server fail-over configurations are designed to prevent this sort of thing, but there are compromises between security and availability that might sufficiently compromise security to allow an double spend to be recorded.
*Owners of blockchains who have configured for high availability at the expense of risking double spend should expect to lose shares from their personal holding pool to "make whole" victims of successful double spend recording, or lose their shareholders' faith in the value of their shares.
Like insurance, there is a risk/reward balance to consider - and if successful exploits become too expensive to deal with, then the configuration should abandon availability and revert to a completely secure from double spend configuraton.
One of the best defenses that small blockchains have against DoS attacks is their small total value. Just like people rarely bother to DoS individuals' home servers, millions of small blockchain servers each with small value makes a diffuse attack surface with little value at any point. Attackers might try a "roving eye" in an attempt to pick off a little value from each of a large number of little servers in rapid succession, but if the servers are configured for security over availability, then they should resist the DoS attack and the DoS attack should quickly move on to other blockchains looking for a vulnerable one, hopefully resulting in a minimal or even un-noticable disruption of normal operations.
When an attacker has managed to compromise a server and replace AOR or AOV software with a malicious copy, then can't actually record invalid transactions, because invalid transactions are invalid on their face, the servers don't know the secret keys and therefore cannot manufacture fraudulent assignment records unless they also possess the secret keys, which are never sent to the server. They can communicate with AOE/AOS software and pretend to record a transaction which they will later drop from the blockchain record, but that will quickly be discovered by alternate AOV servers and anyone who checks for the presence of the promised page in a block.
Only software which handles secret keys has the potential to "steal" value, and while this does include AOE and AOS applications, AOI is probably the most vulnerable because it is usually setup to trade automatically. A compromised AOI could behave normally until triggered remotely to suddenly sell low and/or buy high, depleting the owner's value by giving it away to other traders.
Use of complete certified server images is one of the better defenses for all server operators, any vulnerabilities discovered can be quickly shared throughout the community. Attempting to "dual purpose" a server to handle other duties like serving websites is inviting creative attackers like Mal to teach you an expensive lesson in network security.
Replacement, or Trojan attacks on AOE and AOS client software have the obvious ability to steal the secret keys that they hold directly. This is a common problem for all cryptocurrency wallet software addressed by the usual app store certifications of authenticity, large numbers of users on the app store, identification of malware by the app stores and malware scanners, signed code, etc.
Some traders play within the rules but still subvert the intent of other traders. For instance, Bob and Charlie had an implicit realtionship where, early on, Bob was selling BCG for EC$20 to Eddie in a large chunk. Eddie was selling smaller chunks of BCG to Charlie for EC$25 each, and Charlie was selling individual BCG to customers at Bob's cart on the spot for EC$32.40 each. Bob, Eddie and Charlie were all happy with this arrangement, but after Bob started selling BCG to the open market, Quincy came in and started buying BCG from Bob for a little more, and selling to his customers for a little less. On a straight numerical analysis, this helps both Bob and his customers with more efficient pricing, but it cuts out Eddie and Charlie who were helping Bob through promotions. Bob can cut Quincy out of the loop, if he wants to, by setting his AOI prices higher than what he sells to Eddie or Charlie for in person. Gene also helped the island issues setup recording, transaction and querying fees that helped to slant the system in favor of the intended forms of local trades rather than involving unseen investors, but the unseen investors still occasionally find ways they can make money in the system.
Ultimately, the owners of issues set the rules for how their issues trade and who the investments are attractive to. Surprising amounts of outside investment can and do find their way into issues that were originally intended to be locally traded, and this isn't an all bad thing - that investment brings extra capital into the island economy, but it also exports some of the profits - so it needs to be considered carefully. Ultimately, as long as the blockchain owners keep their ability to repay debt in a realistic range, things should work out well for everyone. Oversight from experienced financiers can help to keep things running smoothly, and to everyone's satisfaction.
Unusual blockchain rules, like high recording fees, can be another form of "Legal cheating" where the buyer doesn't realize up front what they are getting into because the ususual rules are disclosed in fine print or a thick click-through license that most people effectively ignore. This is where dealing locally, with persons you recognize, has value. The less well you know your business partner and the more value you are trading with them, the more carefully you should proceed. When entering an agreement worth thousands of dollars, it can be worthwhile to have the agreement analyzed by someone you trust who is knowledgable about the terms and their implications before proceeding. Smaller transactions with short durations are much easier to try at risk and if you don't like the fee structure, use an alternate vendor or form of payment next time.
29 July 2018
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE