Security through obscurity is fine if it's an additional layer in a well thought out security implementation. I've build a bespoke Node.js site/service where I sometimes have to kick out clients due to various reasons. I sometimes fear reprisal and have to consider a targeted attack on my infrastructure. And indeed I do get the occasional hack attempt with for instance hand crafted sql injection attempts (I receive an instant notification when this happens). The best approach in hardening your infrastructure I think is trying to hack your own service by trying a plethora of methods like sql injection attacks or denial of service attacks on your public api's.
The entire crypto ecosystem seems insane to me. So for your money to be safe - you need to be sure that largely anonymous devs wrote bug-free code on some of the most complex parts of implementing already complex logical proofs. Oh and the Red Team has hundreds of millions of dollars of incentive to line-by-line your code and exploit it. Yeesh.
Writing programs that work is indeed hard. I suspect that the folks writing code for space exploration are good at their job. But it is different dealing with adversarial behavior.
> But it is different dealing with adversarial behavior.
That's your opinion. Integration tests on another planet are just as hard as integration tests across a crypto bridge. One can even argue that an integration test on another planet is more difficult.
Right - but I'm not personally trying to orbit Mars and 0% of my net worth is tied up in NASA contractors getting their units right, so that code quality doesn't impact me at all. Also no hopelessly conflicted VCs are underwriting Superbowl ads to get me to store my money with the next Climate Orbiter.
Early days of the internet, people were afraid to put their credit card into a website.
The main reason we are not afraid to do this today is because we usually get a refund if there is an issue. This is subsidized with the profits the credit card companies make from that 16%+ APY they charge people with revolving debt.
Credit card companies do all sorts of silly advertisements and cards get hacked all the time...
We can go in circles on these comparisons all day long. We have a choice... either keep the status quo, or try to work towards a future where we don't have to give up our privacy and information in order to just buy something on the internet so that we can have ads follow us around.
Whether cryptocurrencies are that solution, is irrelevant... the part where people are working on these sorts of things at all, is what I care about. I personally, would rather be able to provide liquidity and take out a loan without having to ask permission first.
This is because such bridges rely on proofs derived from other blockchains over which validators have no visibility. These add a huge amount of complexity and increase the attack surface. Simpler bridges such as capitalisk-dex https://github.com/Capitalisk/capitalisk-dex (written with only 5K lines of code including dependencies) have a lot smaller attack surface. The principle behind it is to rely on the security of underlying blockchains instead of adding a separate proof mechanism on top; DEX validator nodes have direct visibility over participating blockchains and work directly with on-chain data so they can verify everything directly using each blockchain's native cryptographic clients.
Isn't this the purpose behind tech like State Proofs on the Algorand network, i.e. trustless cross-chain activity is basically solved at this point + deprecates the need for any intermediary trusted bridges:
There is no silver bullet, every approach has benefits and drawbacks.
One of the drawbacks of the Algorand approach is that both participating blockchains involved a swap need to be aware of each other's block signers/validators in order to be able to verify each other's proofs.
These validator lists need to be kept up to date on both blockchains and this adds performance costs (since block validators can change over time).
A blockchain which serves as a hub for many other blockchains (such as the Algorand mainchain) would have to keep track of the state of validators on many different blockchains.
Recurring fees need to be paid in order to keep track of validator lists. This is not suitable for low-volume markets with low fees since trading fees need to be sufficient to cover the ongoing blockchain fees.
The Algorand approach is only suitable for certain blockchains where the block validator list is relatively stable and predictable, it's not suitable for a broad range of consensus mechanisms including proof of work.
With Algorand, the proof-generation Algorithm should ideally be baked into the blockchain consensus mechanism (this adds complexity and performance costs/fees to the blockchain).
Aside from having the proof algorithm baked into the blockchain's code, the alternative approach is to have a separate federation of 'proof validators' on each chain which are distinct from block validators...
This setup has essentially the same security characteristics as a standard multi-chain federated bridge (whose validators have visibility over both participating blockchains) except it has more complexity (risk/attack surface).
The benefit of the Algorand approach (assuming that the proof-generation is baked directly into the blockchain logic) is that it offers the maximum degree of decentralization (which matches that of the underlying blockchains). Though this is at the cost of higher fees. Markets based on it would have to have good volume in order to make it viable.
Finally, in practice, most smart contracts are controlled and can be updated by certain multisig wallets (and their members) so they're really just federations behind the scenes.
I disagree. My entire backend is written in Typescript and maintenance and feature development pace is incredible. It's been this way for years now and I cannot see myself switching to Go or Java anytime soon.
The pace is only "incredible" if you've never spent a year using a truly productive back-end language like Ruby, Elixir, or to a lesser degree PHP or Python.
Golang and Java are both tilted more towards performance and enterprise-friendliness than dev productivity and JS/TS are in the middle of the spectrum.
I use GraphQL (postgraphile) for my admin backend crud. This allowed me to do some incredible fast development with only minimal customisation (couple of PostgreSQL functions). Anything outside the happy path is handled by a REST API. Maybe we shouldn't think in absolutes, eg: only use GraphQL. For the same reasons I use an ORM, and raw queries where it matters most. The cliché holds true: use the right tool for the job.
Swpapped my G suite custom domain accounts for mailcow and never looked back. Luckily I never used these accounts for paid apps or other Google specific services.
