I think it's more likely that more people are becoming obese because of exactly one factor: age. They are living artificially prolonged lifetimes due to access to adequate food and to medicine. It's easier to get fat when you are 50 than when you are 30 because of the natural changes in your metabolism.

:-)

You make it sound like starving people are getting fat too.

If they are becoming obese, the particular individual has a surplus of caloric intake, if only for this year or month. This is not to say that they have proper nutrition. So I am not at all clear that the fact that there is obesity in the third world is confounding evidence.

For most of the existence of mankind and indeed all of mankind's progenitors, having too much food was a rare problem and being hungry all of the time was a fact of life. We are not necessarily well-evolved to handle it. So, no surprise that we eat to repletion and are still hungry. You don't really have any reason to look at it as an illness caused by anything other than too much food.

Martin,

The last time I had a professional video produced, I paid $5000 for a one-minute commercial, and those were rock-bottom prices from hungry people who wanted it for their own portfolio. I doubt I could get that today. $8000 for the entire conference is really volunteer work on Gary's part.

Someone's got to pay for it. One alternative would be to get a corporate sponsor and give them a keynote, which is what so many conferences do, but that would be abandoning our editorial independence. Having Gary fund his own operation through Kickstarter without burdening the conference is what we're doing. We're really lucky we could get that.

We do charge entry to the convention. We get really nice facilities for the people who actually travel there and for the speakers. Last year's location was subperb. But I don't see why they should actually subsidize the folks who do not attend.

I think TAPR's policy is that the presentations be freely redistributable, but I don't know what they and Gary have discussed. I am one of the speakers and have always made sure that my own talk would be freely redistributable. I wouldn't really want it to be modifiable except for translation and quotes, since it's a work of opinion. Nobody should get the right to modify the video in such a way as to make my opinion seem like it's anything other than what it is.

If I remember correctly, it was 4 video channels last year: tracking on presenter, proscenium, audience, projector.

Yes. I put in $100, and I am asking other people to put in money to sponsor these programs so that everyone, including people who did not put in any money at all, can see them for free. If you look at the 150+ videos, you can see that Gary's pretty good at this (and he brought a really professional-seeming cameraman to Hamvention, too) and the programs are interesting. Even if at least four of them feature yours truly :-) He filmed every one of the talks at the TAPR DCC last year (and has filmed for the past 5 years) and it costs him about $8000 to drive there from North Carolina to Austin, Texas; to bring his equipment and to keep it maintained, to stay in a motel, to run a multi-camera shoot for every talk in the conference, and to get some fair compensation for his time in editing (and he does a really good job at that).

My sense is that the MEAN Stack (Mongo, Express, AngularJS, Node) is sort of winning. There's some packaging of it over at mean.io.

Personally, I'm really getting interested in Meteor (www.meteor.com). Watch the videos, and realize I saw a smart non-coder go from zero to *ridiculously* interactive site design in three months.

Using blockchain technology for decentralized consensus.

If you are thinking about using bitcoin style proof of work, then I'd say that is a poor choice. It is an extreme waste of processing power, and it is not even needed for DNS. The purpose of the proof of work is to prevent double spending. But if you tried to perform a double-spending like action on a DNS system build on similar principles, the only damage you'd cause would be to your own domain.

But by all means, let's get data and hosting decoupled. DNSSEC provides the ability to validate records, wherever you got them from. But it still has the centralized authority. I'd rather see that once a zone hand over authority over a subdomain to a different public key, then a signature with that key has to be used to hand authority back or transfer it to a new key.

it it possible or even practical to identify a bitcoin as having been a "direct descendant" of a coin involved in a given transaction and/or as a coin that has been "co-mingled" with such a coin?

Definitely. That is easy to do. However since each transaction can have multiple inputs and outputs, the set of descendants is likely to grow over time, until eventually most bitcoins are descendants of that transaction.

it may make it practical to for major players and for that matter anyone who uses BC to "locally blacklist" seized bitcoins.

If there isn't any consensus in the "community", then such a blacklist is unlikely to have any effect.

If some miners decide to blacklist transactions involving certain coins, then other miners are just going to pick them up. If only a minority of miners are in on the blacklisting, then this is going to cause a fork in the blockchain. Other miners have to decide, which fork they are going to bet their resources on. If there isn't consensus on what to blacklist, there could be so many forks blacklisting different subsets, that each fork is going to become irrelevant leaving only the chain with no blacklisting as viable.

Even if you could manage to get a majority of miners to agree on exactly what should be blacklisted, it is of questionable value to the miners to attempt blacklisting. It could be seen as introducing a dangerous precedence for introducing blacklists. This would introduce a new and even more unpredictable danger to anybody owning bitcoins.

Traders could decide to blacklist certain bitcoins. This would mean you would refuse to accept blacklisted coins. But if you are selling goods for bitcoins, then you'd have to announce in advance, which coins you consider blacklisted, otherwise you'd have disputes where the buyer of goods says they have paid, but seller of goods says the received bitcoins are no-good. And as receiver of bitcoins you'd also have to decide how diluted the blacklisted bitcoins would have to be, before you'd accept them. And in all, there'd have to be consensus about both the set of blacklisted bitcoins and the dilution threshold. Otherwise nobody will know, if the bitcoins they are accepting are good or not, and without such knowledge blacklisting wouldn't have the intended effect, instead you'd just be rejecting arbitrary payments, you might as well flip a coin and say no-thanks to a certain payment.

I think the only consensus that has a real chance of being reached is that bitcoins are not blacklisted.

Remember when we had a Debian system on the biosciences mission? They scrubbed the whole mission after they were already in space due to a fuel-cell issue that I think turned out to be a faulty sensor, and flew the entire mission a second time.

Keep in mind; if the miners did have to communicate with the pools constantly and synchronously with their mining, it could slow down their mining, and therefore give them a competitive disadvantage.

True. I was assuming it was obvious, that the communication had to be asynchronous. And I can't see any reason to communicate with other pools more often than once per block.

Once a node has started computing, it should be able to go on for quite a while without any communication. If the node doesn't hear anything else, it should just keep doing whatever it was doing. The only thing that can render the continued computation completely pointless for the node is if a node somewhere (in the same pool or any other pool) successfully mines a block. If communication has been totally dead for an hour, it is probably a waste of energy to keep trying to mine a block, since somebody else likely mined it already. But if you haven't heard anything for five minutes, just keep trying to mine the same block you were already working on.

This means the most important information to get synchronized between nodes is the fact that somebody mined a block. This should be totally independent of the pool, so this can be communicated between nodes even if they are in separate pools.

The other information a node needs to receive is information about which transactions to include in the block. It's no big deal if that information is lagging a bit behind. You could update the list of transactions multiple times while trying to complete a block, but if it lags a couple of blocks behind, nothing is going to break.

But why? We couldn't understand Linear B

That shouldn't be a prerequisite for including it. After all, having the text represented on a computer would be a useful tool in getting to understand it.