14th of Novemblog
I realize that I've spent thousands of hours in thought, hundreds of hours in code, and tens of hours trying to describe and perfect cross chain security. I've probably spent the most time with 
If you want real world security there is no perfect solution. It doesn't matter how big your lock is there is always more dynamite/nuclear warheads/asteroids/solar expansion/black holes out there. Engineers therefore have to think in terms of cost-benefit analysis. The chance of an asteroid strike is tiny compared to the cost of mitigating it to preserve my Brownie the Bear (Beanie Baby – $20,000). Would you spend more for a bike lock than a bike?
Likewise, if I want to steal Brownie the Bear, it should cost me less than $20,000.
The motives of an attack aren't always financial. For instance, the bombing of the Georgia Guidestones only cost resources to carry out and carried a risk of 20 years in prison... but destruction seemed to be the only motivation. Likewise, in a cryptocurrency ecosystem the goals of an attack could be as varied as breaking trust in an ecosystem, writing an academic paper, or just because "they could".
We can minimize most potential losses in our ecosystem through "fork protection." Any of our valuable data, internal assets, can once again be collectively decided to be the accurate copy for nearly any circumstance. This already happens quite often on most chains, Hive included. It's just the differing opinion of truth is usually 1 account. This goes back to an old argument: Code is Law... well I guess it's like a legal law: One that can be interpreted and changed.
However, there is a world of difference in internal and external assets. Oddly enough these two very different things are identical in their own contexts. Coins on Hive (Hive, HBD, Vests/HP) are internal... on Hive, and external in any other context. That includes when you own them, when the are wrapped on a different chain, or when they are in an exchange account. Just the same, SPK, LARYNX, DLUX, DUAT are internal assets in their chains... and external assets when you own them, they are wrapped, or they are in an exchange account.
This is a little different than bearer instruments like cash. As long as you have the cash it's a quasi internal asset. That's also what makes cash an easy thing to steal... once it's not in your possession it's not your asset. In cryptocurrencies you have to "convince the world" that you can change the state of your data. Through cryptographic transaction signing.
In HoneyComb most data is an internal asset, and has fork protection. As long as there is a group of people who can agree what is valid... then it's impossible to change that through any brute force means, social engineering and politicing aside.
The people interested in HoneyComb data will always be a larger set of people than those that manage HoneyComb data. The same is true for bitcoin, and ETH, and every financial instrument ever conceived. Try giving a newborn a $2 bill, savings bond, a college fund, or a bitcoin to understand this point. The cost of goods will fluctuate, interest rates(the price of money) will fluctuate, college tutions will change in vale... and bitcoin sure isn't going to be the bastion of stability, and the child never had any impact on this at all.
So depending on the system, a small number of people can have a larger than their weights outcome on the system. Bitcoin is really the first financial scheme to protect itself from tampering by making honest participation more valuable than dishonest participation. This doesn't at all mean bitcoins as an external asset are immune to the same kinds of issues as any other asset (Stares at FTX administrators) but internally we have collectively probed and found no chinks in it's protocol.
Bitcoin's cost to secure comes with quite the pricetag though.
This is a wild chart, and one thing it doesn't speak to in terms of scaling, is that it's also impossible to scale PoW systems in a parallel way. As a 51% attack on any competing infrastructure would only take the smallest fraction of the bitcoin network. You'd likely never know that a container full of mining rigs somewhere got pointed towards inserting a malicious transaction on a bitcoin-esque clone.
Which means, we are barred from PoW systems both because they can't scale the number of transactions they do to something broadly interactive and because any parallel system will suffer from wildly varying incentives on where to use their PoW hashes.
Hive uses a Delegated Proof of Stake (DPoS) system to try and give everybody a say in who represents their interests (Vote for my witness 😜 ) in keeping the internal data in a pristine state.
HoneyComb uses a Proof of Stake (PoS) system to manage external assets.
When conceptualizing this system my internal model was how would I send a valuable item via a third party? If I wanted to mail Brownie the Bear to a buyer. What would need to happen to make sure that no matter what happened, there would be no party to the transaction that lost value? Researching this lead me to the only known conclusion: collateral.
So my courier would need to be bonded for at least $20,000 before I'd be willing to part with Brownie... if my courier takes Brownie, all he did was purchase it. My recipient would be a little miffed I'm sure, but at least he'd have his $20,000 back.
What can be an incredibly complex system in the real world is only a few thousand lines of code in HoneyComb. Anybody who wants to run a node, can run a node. They are pretty cheap to run... less than $5/month. If you want a share of the DEX fees, you can lock some tokens as collateral. If you've locked enough to have a positive impact on ecosystem(and are one of the top 25-79 accounts that do so depending on the communities votes) then you'll receive an equal share of the DEX fees. If you've locked more than most of the nodes in that group you'll be assigned as a key holder for external assets; and you're collateral will now help determine the safety limit on the open orders carried by the network.
So let's say there are 25 key holders, simple majority controls the funds and the value of the poorest 13 of those key holders is the maximum steady state wallet size. We can't completely control inflows to this account, but we can near instantly refund or manage orders over this size. Especially with One Block Irreversibility there can be as few as 3 seconds before this under collateralization can be safely managed. Outside of this situation, any combination of the 13 required keyholders to steal funds will result in the community removing their collateral.
Ideally, when the chain recovers the new multi-sig DEX account will be funded (open orders replaced) by the honest community members who will split the collateral forfeit by the dishonest(cheaper tokens). Alternatively, the collateral will be used to fill the open orders, though there could be an imbalance here if extremely pessimistic orders were open (0.001 hive for 100000000 DLUX for instance)... A mixture of the two could preserve token value the best.
With this paradigm we are ensuring it would be more beneficial to just use the DEX to trade your tokens. The astute among you may point out that time locks on collateral actually prevent this assurance because the time value of assets is an unknown... and well, you're right. No system is prefect... and HoneyComb will strive to be better at managing DEX transaction, and can with the help of everybody who's voted for our funding proposals (SPK and HoneyComb alike).
That's really it. Attacks here can only alter fork protected internal data... or the managed collateralized external funds on Hive. There should be no valuable attack possible. And thus far coding errors have only lost peanuts that have been returned when asked. (See yesterday's blog for an example)
Thanks for supporting me, my software, and it's communities. Looking around you'll see we are in a much better place than "fiat" promises alone.
