HN user
Followup - I'd actually been using chrome a bit more heavily; and was wanting to use FF more, just to support open standards. One of the main things I was missing was being able to type in google docs domain, tab, and type a document. I was planning to research how to make something similar work in FF, and now I know how, and that they're removing it :(
That seems really ass-backward, and not just because I use the search feature a lot.
If I'm reading that right, they're deprecating support for discoverable browser-independant markup for searches; and replacing it with the requirement that each site actively develop (and maintain!) a software plugin for every browser their users might want to use.
The whole point of a "user agent" was to go out and do things for me on the web; and the idealistic goal was that each person could choose an agent suited for them, which then had tools to programmatically discover and interact with the web in a common manner (reducing engineering load on the webdevs).
And I don't want to try and use a separate search tool (with new flashing graphics and ads!!!!) for every site I go to... I want a single search tool, like FF offers right now. (Aside: not to mention chrome's "auto-discovery of opensearch when you tab after typing a domain" is actually MORE useful than FF's manual mode!).
Taking a step back and removing support for a declarative api seems to me like the really wrong direction for an open web. Instead of sites supporting a single declarative browser-independent markup; they now have to deal with a long tail of (2-3 + who knows how many) browsers; and users with a niche browser have to spend effort convincing every site to support their browser.
Why not try to improve the opensearch markup instead?
You may disagree that it's the real Bitcoin, but it's undoubtedly open to interpretation
It really isn't open to interpretation. And that is why people have been disparagingly calling it a different name; because the insistence that it's "the real Bitcoin" lessens it's credibility.
Why is Bitcoin Gold not the real Bitcoin? It's got a more ASIC-resistant proof of work, that's surely also in line with Satoshi's original vision? IMO, that's a much better reason, if adherence to the original whitepaper is what we're measuring by, since it reduces mining centralization. (Heck, if BCH adopted an ASCI-resistant PoW, I'll view in a new light!).
But you have to let things evolve. Software is rarely perfect out of the gate. Massive p2p software in particular is such a very new thing, there's going to be all kinds of bugs and dead ends. There may be ways to optimize and polish those dead ends to make them the best they can be, but it won't change the fundamentals of them.
And there's tons of levers and settings inside bitcoin. I don't think they're all set right (BCH's new difficulty algorithm seems like an interesting idea, in fact). But one thing that seems to be clear across the biggest coins... a worldwide distributed blockchain ledger just takes too darn long to handle p2p payments worldwide at a reasonable KiB/s. Even ETH, as fast as it is, was brought down by cryptokitties.
The coin that succeeds is going to have to solve that in some fashion. And running all the world's transactions through every node, upping the blocksize as needed, isn't going to solve the problem.
That's pretty much exactly how the EtherDelta smart contract works. The contract can only move coins you've signed an order for, and only when it's properly paired with a matching counter-order.
I think the mainly catch would be scaling the speed (etherdelta is limited to the ETH network block rate). I don't know too much about lightning's details, but given that they've demonstrated atomic cross-chain swaps, I bet it's set up to handle something exactly like what's needed.
Which is quite exciting... I just always moderate my enthusiasm because for all complex software projects, the devil (and 80% of the work) is in the details :)
Followup just to clarify: The reason smart contracts drastically mitigate "server compromise" is that compromising / altering the operation of the VM (and not merely exploiting a bug) requires a 51% attack on the entire network. That should generally be a MUCH more expensive undertaking than the value of any given smart contract (under the assumption that the network will be valued at least 2x more than any of it's participating apps).
Oh, I definitely think they can. Didn't mean to imply otherwise!
I do think the surface area for attack is much more limited, since the code is innately public (unlike centralized trading houses).
That (in theory) should make them more secure, particularly if considered in terms of the transparency provided. I also think theorem proving, and languages amenable to it, can greatly reduce the surface area even further; reducing it down to a matter of reviewing what assertions the theorem prover was handed, along with trusting the VM's implementation itself. (The later is also helped by having multiple independant implementations).
But I don't think the tech is there yet. The languages currently being used aren't the greatest for theorem proving; no one's actually done much of that in practice anyways; there aren't "best practices" for upgrading your smart contract when a bug is found; and there's ALWAYS an assertion someone forgot to add to the test suite.
But I do think smart contracts could remove "server compromise" and "unauditable code" from the list of main dangers of an exchange, which does seem quite useful in the long term (once the ecosystem fleshes out a bit).
That is one reason why I'm actually kinda wild about distributed exchange like etherdelta (as proof of concept, at least). The security model is such that it literally doesn't exist in any country, anywhere in the world; doesn't have servers that can be hacked, etc.
(Admittedly the website is housed somewhere, but it's little more than a GUI shell for signing procedure calls, you could run it locally or interact directly).
I think the big issue hindering that model is that they need something allowing users to pipe into traditional currencies. So far all the solutions to that have been IOU tokens like USDT tethers; which end up generating governance headaches of their own, as their value desyncs from their base currency due to arbitrage & supply issues.
1) No counterparty risk. Everyone can get hacked, but coinbase being hacked shouldn't every, under any circumstances result in me loosing any bitcoin they hold on my behalf.
This point may prove to be very sticky.
It might be solvable with smart contracts... consider ethereum's https://www.etherdelta.com, which operates as an auditable smart contract. Your money literally can't be stolen without your private key; even when it's held in escrow by the contract. (Of course, a bug in the contract code could let someone get through; but that's all out in the open, so easier to check for).
I could see something like that being done, with the individual trade data being signed, but held off-chain until the user wanted to make a transfer (then ALL signed movements related to them could be consolidated on the chain).
---
Short of that, a centralized exchange is gonna run into the fundamental issue that cryptocurrencies have value because of a few properties; Chief among them being that they can be moved atomically, and with non-repudiation. Those two alone make theft a LOT easier to get away with once achieved.
Being able to walk back such thefts would require general consensus of the network. For most coins, the majority of participants would see that as a fatal weakening of the protocol's guarantees, and drop out. The highest profile rollback I can think of was ETH's june 2017 DAO incident. Even that proved rather controversial: though the market voted in favor in the end, it was a messy out-of-band solution, which may not work again.
---
Conversely, some lesser coins such as NAV actually formalized "consensus voting" on such out-of-band issues as part of their network protocol. I could potentially see that being used as a final band-aid, though "tyranny of the majority" issues would seriously need solving. NAV uses proof-of-stake, though, which certainly helps keep their voting in the "put your money where your mouth is" territory.
All in all, I think there are potentially some trustless and "semi-trustless consensus" methods that could solve this issue in revolutionary ways. But none of them are tested... Coinbase may just have to get themselves massively insured using traditional methods, at least for a few more years as the tech expands.
If they have the money to buy hashing hardware that's competitive, staking that money has a lower barrier to entry... You don't need space, hardware, or technical experience to assemble the rig. Just $.
That doesn't fit. Per bitinfocharts.com the coin with the highest txn rate is Ethereum, followed closely by Bitcoin. The others are far behind. I'd say it's seeing a lot of use.
Segwit was a soft-fork upgrade. It only takes effect if you move to a Segwit compatible wallet and send from there.
Which tells me people don't actually care enough, or they'd be doing that.
Which makes me wonder about the validity of the majority of the complaints.
Ethereum's Casper uses the solution that while validator A could double-vote for multiple blocks, validator B could take those multiple vote messages, and submit them as cryptographic proof of A's dishonesty. By submitting such proof, the protocol would allow slashing A's stake, and giving some portion to B as a reward for catching them. Thus validators are strongly incentivized to only vote for one block at the end of the chain.
Not that I'm totally sold on it, or grok it fully, but from my rough understanding the very highest level (for Ethereum's Casper)...
The idea is that a double-spend attempt by a cartel of validators could be included in a new block as cryptographic proof to used take away their stake entirely ("slashing" it). Where a BTC miner would merely lose the cost of an attempted double spend block, and could keep mining more bad blocks; removing their stake completely is like burning down their rig.
In order to prevent that punishment, they'd have to control >2/3 of the staked coins on the network. Which means as long as total amount staked grows in value proportional to the network, this will be incredibly expensive. By adding rewards for staking, this further incentives long-term holders to stake part of their holdings, to secure the network.
"ascii" the codec does exist under python. It's strictly defined as byte values 0-127, anything in the 128-255 range causes a decoding error...
>>> b"abc\xf0".decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 3
As the article points out, in a directed attack it just has to be an outage which affects the target server: e.g. compromise a firewall, lan DNS, or managed switch in front of the server and "block" duo.
Not to mention shorewall, which IMO provides a really nice abstraction over iptables, that fits 90% of the needs out there.
Would love to know this myself.
I'm in process of moving my company's main web app to python 3, and standardized on 3.5 to match Debian 9.
But python 3.6 has so many cpu & memory improvements (not to mention things like f'' strings), seriously considering installing custom copy of 3.6... though not sure if I want the burden of maintaining my own copy of everything that will affect.
Then again... "Debian stable" being rock solid stable is why I stick with it for production; if their caution in this is the price I pay, it's worth it.
The post posits that, to handle the burden of legacy instructions, an "obvious technically-appealing approach (is) starting over with a clean-sheet architecture".
The approach that immediately occurred to me would be have a layer that translates the legacy instructions into modern equivalents; without as much concern if they are slower to execute in their new form (they're legacy, after all, right?).
Of course, doing something like that is probably nowhere near trivial, the devil's always in the details.
But I bet this is already being done at the microcode level. Stepping things up to having a published agreement about which instructions were globally considered "legacy", and guidelines for what their equivalents were, would go a long was towards allowing a general feeling that an ISA was evolving, rather than just accumulating weight upon weight.
Wow! Thanks for mentioning OODA (https://en.wikipedia.org/wiki/OODA_loop), never heard of that before. That's a really intriguing concept... so many cogsci, ML, netsec, and game theory connections. While the wikipedia page is rather sparse, it's already added a few things to my reading pile.
Does anyone know if [Shorewall](http://shorewall.org/) has plans to support nftables, or is it staying on iptables for now?
While I'm excited to hear about a simplified abstraction at the kernel level, for most setups I've had to configure, I really like the highlevel abstraction it provides.
At my company we tend to use "NOTE:" just to be aware of something, "XXX:" when something's functional, but has room for improvement, "TODO:" when functionality's missing, and "FIXME:" when it's plain broken.
In that context the XXX's are kinda nice to have... we can mark there's something to work on; but only search for TODO/FIXME when looking for things that will actually impact currently needed operations.
Not quite turnkey, but openvpn is essentially tls over udp with an ip tunnel on top
There was an article a while back -- https://news.ycombinator.com/item?id=1144548 -- purporting that the efficient market hypothesis is true if and only if P = NP. ... which I'd argue implies social science is overly optimistic about that hypothesis.
One bit of trivia I really love is why "DEL" is at 127 -- weirdly way away from all the control codes.
It's because 0x7F is all ASCII bits set to "1". Back in the early punch card (and telegraph?) days, if there was a typo, you couldn't "unpunch" a hole to make it a 0 again, but you could punch out all the rest of them, indicating "ignore this char, I've deleted it" -- 0b1111111.
source: http://www.trafficways.org/ascii/ascii.pdf which is a really neat read if you like that sort of thing :)
Actually, per a snopes article (http://www.snopes.com/donald-drumpf), the Drumpf to Trump transition may have occurred because the former was more German sounding, and there was a good bit of anti-german hatred at the time.
What makes Donald Trump's action so sickenly selfish is that a better life is why his grandfather Friedrich Drumpf immigrated from Bavaria.
Though one could argue 3 generations later that act of immigration is not benefitting the US.
Is that a typo? Shouldn't he be taxing exports?
Taxes on imports just raise the price for Americans, it's taxes on exports that would bring money into America.
I think a lot of this debate argues for the sysadmin role being part of the dev team. The only real way to get both constraints (production stability and update to date fixes/features) is to have fast feedback between the interest holders of two sides.
In the python-specific case -- the requirements.in / .txt files for the virtualenv should be part of the software VCS, but the sysadmin should be able to edit & pin things just like the devs, so that they can bring their expertise to the container, rather than having to fight it.
---
Mind you, my opinion might not scale - I'm part of a small enough team that I'm holding both those roles, but I try make sure to spent time wearing both "hats", so that one role doesn't get more man-hours clocked.
IOUs that can't be repudiated, payments that can be cryptographically proven, payments that can have conditional logic attached (e.g. third party escrow, without third party having access to the money) -- and all without the need of a centralized authority or PKI system. Those are the real values of the bitcoin system.
Mind you, there are a few downsides too - potential to create transactional race conditions if you control enough of the system; difficulty changing into other currencies; architectural decisions yet to be ironed out about how to scale to a mass audience.
Lack of ability to reverse a transaction could also be seen as a negative in certain lights -- no "visa, cancel this charge, they scammed me".
That's a good example of where I think a gui has an advantage.
For the example I gave, unless the hunks were asymetrically distributed, `git add -p` would require pressing "n" 20 times to skip through the excluded hunks (among other things), even when the user could visually see all the hunks, and know which ones they wanted. Where as gui would only require the clicks to select the "y" hunks.
I realize this is arguing a difference in the efficiency, not capability, of the UIs; but that's basically my point. The use-cases where one or the other is optimal are too closely situated together in the problem space to say one is inherently the better choice, even for VCS tasks.
While command line interaction may allow the user to receive a whole screen's worth of information at once, it forces them to interact with it in a serial fashion, regardless of whether out-of-order interaction with on-screen elements would allow them to complete the task faster.