namecast

Assuming your house is rentable and there's a liquid market for rentals in your neck of the woods - and that's an untenable assumption.

"Property can be rented for profit" and "Your specific property can be rented profit" are different assertions.

Neato. Just one minor nitpick: I see two points where vim is invoked but no way to tell what edits were made to the files (though it's easy enough to guess from the filenames).

Switch those two out with appropriate sed or echo commands, add a bash shebang at line 1, and baby, you've got a stew going!

FWIW, if you have to look to the Soviets to find favorable counterexamples, that's not a good sign, is it?

Found the Red Sox fan... ;)

No, only that the article is being misleading in it's breathless clickbaitiness.

The quote is absolutely in line with the article; actually including the quote in the article would have rendered the headline 'Bitcoin dev thinks blockchains for banks are way cooler, has thought so for months, and is reluctantly moving on'; that might be a fun article to read, but it's not frontpaging HN.

Mike's resolution was apparently to join up with a consortium of banks back in November:

http://bravenewcoin.com/news/30-top-banks-and-mike-hearn-hav...

Read the article, he was clearly laying the groundwork for this move back in Thanksgiving.

“The current Bitcoin system, I mean the system we actually use today with the block chain, isn't going to change the world at all due to the 1mb limit. … So if I have a choice between helping the existing financial system build something better than what they have today that resembles Bitcoin, or helping the Bitcoin community build something worse than what they have today that resembles banking, then I may as well go where the users are and work with the banks."

Worth reminding people:

On August 15th, 2015, Mike Hearn announced Bitcoin XT, and his attempt to fork the blockchain: https://medium.com/faith-and-future/why-is-bitcoin-forking-d...

On January 14th, 2016, 5 months later, Mike has unilaterally declared Bitcoin to be a failed experiment.

In the intervening period, support for XT was at best minimal, and that's being charitable.

There is a phrase we use in my neck of the woods when developers behave like this, and "responsible grown up behavior" isn't it.

I get why that would jump out immediately and you'd stop reading from there on, but straight after that block of code, from the article:

"Now I'm certain that a lot of readers will have something to say about the style or the efficiency of this shell script, I just wrote it that way to highlight what steps need to be taken:

    it retrieves a TXT record, and doesn't output anything if the record doesn't exist
    if unbound-host has not confirmed that the record was correctly DNSSEC signed, it doesn't output anything
    if the above is successful, it filters out the text to return only the public key
    it doesn't try to do anything complex, because complexity is the enemy of security (or at least, that’s a point of view that I share with a few people)
    it works with multiple records

I'm sure you will write your own program to do the above. Just make sure it works only when you want it to. It is critical to ensure that it doesn't return anything at least when:

    a record for the corresponding user doesn't exist
    the records are not signed or not properly signed
    the local copy of the root key (/var/unbound/root.key, here) is corrupted.

"

From your profile: https://keybase.io/breakingbits/sigs/DIO92uX_zdSeZEwYeQ74qj1... throws an error. Just FYI.

Neat idea!

Some technical details from clicking through to the github repo for their fork of BIRD, detailing the config and protocol changes you'd need to make for interoperability:

Change in BGP Configuration: In each BGP protocol section you must set a role option. Currently, there are 4 possible values for this option: 1) "provider" - neighbor is your upstream provider; 2) "customer" - neighbor is your customer; 3) "peer" - neighbor is your peer; 4) "internal" - neighbor is part of your AS or company (in case of multiple AS). Without setting a role in BGP protocol section you will receive error message from config parser. Also you could set strict_mode option in BGP protocol section. In this scenario BGP session with your neighbor will be established only if your neighbor also support Roles and corresponding Role is correct.

BGP Protocol modification: There are two main changes in BGP protocol behaviour: 1. BGP Update modification: to routes that were learned from upstreams or peers add special non-transitive attribute “Local Announce” (BGP Path attribute code 19). On links with upstreams and peers filter out routes with determined attribute; 2. BGP Open modification: to OPEN messages add new capability option "Role" (Capability code 38), in which broadcast value of Role configuration option. Establish connection only if speaker and its neighbor have appropriate pair of Roles: (provider, customer), (customer, provider), (peer, peer), (internal, internal).

Etcd (at least up to 2.1, which I'm running now in prod) doesn't bother with niceties like service discovery and failure detection; it's strictly focused on serving as a distributed k/v store. I think that's the biggest difference I can think of.

I'd disagree with the stable/reliable bit; or, at least, I'd note that CoreOS ships with etcd, and fleet (the CoreOS job manager, at least until Kubernetes obviates the need for it...) depends on etcd to function correctly.

The upshot of that is, if you're running a stable release of CoreOS, you have a stable etcd, by definition - or you have a broken cluster that you can't submit jobs to, which would be bad.

From the outside looking in, to me Consul seems to provide more features; I don't doubt that it's awesome, but etcd ships with CoreOS, and when I spin up a new cluster via Cloudformation it's up and waiting for me as soon as I log in. This is a huge selling point, as I am lazy.

At that point, you'll need to have multiple regions in play, and some sort of mechanism to direct traffic to regions when one becomes unreachable (for most people on AWS, this will be Route53).

Devil's advocate, though: if you're concerned about what to do in the event of an AWS regional failure, given how rare an event that is, then you've probably outgrown AWS.

(For most small-to-medium sized startups, I'd advocate setting up statuspage.io and keeping your users informed if you're single homed to an AWS region and that region experiences a catastrophic failure. The math on "how much money you'll lose from the outage" vs. "how much you need to spend implementing proper DR, better than what AWS has in place to keep a region up and running" isn't even close, assuming, say, 1 8 hour regional outage every ~2 years.)

> If you back test over the past 20 years then I'm not sure it helps much as the market of 20 years ago didn't really have any of the major market drives of today's markets

+1, and I'll add a link that argues that data pre-2009 is worthless for a great many (intraday) strategies:

http://www.priceactionlab.com/Blog/2015/07/historical-data-t...

And this is before we even start worrying about in-sample vs. out-of-sample...!

The paragraph before the one you just quoted:

"We Zimbabweans are left shaking our heads, wondering why Americans care more about African animals than about African people."

And the paragraph directly after:

"And please, don’t offer me condolences about Cecil unless you’re also willing to offer me condolences for villagers killed or left hungry by his brethren, by political violence, or by hunger."

"Please don't care about the animals in my country more than you care about me and my countrymen" is a reasonable request. I don't see anything terrible about it. I'm not sure why you dropped the surrounding context.

    alias c='noglob perl -e '\''shift; $x = eval qq(@ARGV); print $x; printf " 0x%x 0%o %b\n", $x, $x, $x'\'' _' ' "'

Quick and easy perl calculator, with octal, decimal and hex output. Example usage:

    root:~$ c 365 * 24 * 6 / (14 +2)
    3285 0xcd5 06325 110011010101

Or complicit. The message posted sounds like a plea to return the recently departed CEO to power, or am I misreading it?

+1 for being awesome - but the OP mentioned 'across the Pacific' - if he's got to transfer 10TB to, say, Sydney or Beijing, I'd bet your upstream won't be the limiting factor, it'll be the congested peering ports and high latency links between the States and APAC providers.

That said, nothing ventured, nothing gained. Maybe try a speed test between the hacker house and the intended AS before anyone ships a drive anywhere, and see if the other end can keep up with you?

I just remembered, GBLX was bought by L3 a few years back - I'm guessing someone has a "tighten up route maps for GBLX ASN" ticket open in their backlog at the Level 3 NOC.

The people managing peering for AS 3356 and AS 3549 should be the same group, no? ("That DB we don't share the URL of" seems to imply as much.)

Yeah... no.

Sorry, but please read what I wrote again. "An extremely small number of people under the proper set of circumstances may potentially benefit from income contingent plans, and then be forgiven after 25 years", is simply not a rational response.

Again, worth noting: there is no risk to the taxpayers for the balance of your loan. You cannot discharge student loans through bankruptcy, and the government can garnish your wages, tax refunds, and social security to repay them.

Worth noting: you cannot default on student loans. The government can and will garnish your wages, tax refunds and social security for them, and you can't discharge them through bankruptcy.

Do you really believe that it didn't turn into billions over the years?

Seriously, add up the billions upon billions we've spent as an industry (in terms of $/KwH delivered to all the datacenters across the world) over the past, say, twenty years, and bitcoin looks downright anemic in comparison. [1]

You might not like that people are choosing to spend money on electric for BTC, but if they weren't, I imagine that juice would just be spent on serving up pics of cute cats with a side of advertising and tracking. Be thankful we found something slightly smarter to do with it.

[1] http://www.nrdc.org/energy/data-center-efficiency-assessment... - 13 billion a year for power to U.S datacenters, according to the NRDC. Slap a moving average on that, account for non-US usage, and scale it back twenty years to the launch of Netscape Navigator and the subsequent rise of colocation, and we're talking more money spent on electricity for the Interweb than most nation states annual GDP.

I actually wouldn't be surprised if it were.

"Hey $ATT_EXECUTIVE - see what happened to [Qwest's CEO] Joe Nacchio? Good. Now go splice me some fiber or you'll be joining him."

Seconded. "Money can't buy happiness, but it can sure chase away the blues". (And the debt collectors and irate landlords, I would add).

Something I just realized - why is this being handled by the SEC and not the CFTC? Don't prediction markets fall under the CFTC's jurisdiction, e.g. Intrade?

I guess given the nature of the prediction market they could have flipped a coin to see who fined them first....

Well stated. Cisco's docs go into great detail on this - they've spent a lot of time thinking about how to address the issues in plain ol' BGP with SoBGP (Secure Origin BGP), and they concluded that determining a BGP speaker is authorized to announce a particular route is impossible in a functioning internetwork.

http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...

and

https://web.eecs.umich.edu/~zmao/eecs589/papers/draft-white-...

provide more detail on this.

Hmm. How about mixing and matching, like by having a DNS record with a special TXT record syntax, e.g. 'IN TXT "gt=yoursha256hash"'. That way you could find your destination via DNS and verify the hash in the TXT record against the blockchain.

None of my comments are TCP specific, but as I said - at 3 PoPs, you won't see routing weirdness; announcing the same prefix from 70 PoPs will cause the likelihood of route instability to increase. For the case of UDP, hopefully no one will notice, as your lost packets will just go to the next available route; for TCP connections, a route withdrawal sending you to the next nearest PoP will lead to a broken connection and clients seeing badness in their browsers.

Anycast is an IPv4 quirk in that it wasn't designed; it "just works" because of the BGP route decision process. Yes, you can announce your prefix out of multiple PoPs, but how people choose to use the routes you announce is where things get "quirky".

In theory there's no difference between announcing a /24 IPv4 and asking us all to accept it, and doing the same with a /48, but in practice you'll burn an unacceptably large amount of IP space, IMHO, and if you tell ARIN that you need a second /48 block because you burned your first with less than 25% utilization, they simply won't let you have it.

Disagreed on your last point. The abundance of prefixes isn't the problem IMHO; it's the acceptance of route announcements from upstreams. If upstreams were to start accepting and passing along more granular routes, maybe we'll start seeing more anycast deployments, but I doubt it.

Depends on who's doing the accepting ;) I actually meant a /48, mea culpa!

I'll leave this here:

https://labs.ripe.net/Members/dbayer/visibility-of-prefix-le...

It's from 2010-ish but still sadly relevant.

It's a protocol layer thing, mostly down to "what prefix sizes can I reasonably expect other providers to accept?"

For IPv4 the answer was a /24; for IPv6 the answer seems to be a /64 at this point, and burning an entire /64 to get a couple of DNS servers (the typical use case for anycast) to resolve slightly faster is overkill. It's also probably a great way to annoy your RIR when they ask 'how the hell did you burn through your initial IPv6 delegation with only two hosts' ;)

EDIT: I meant /48, not /64! Whoops-a-doodle.