vgb2k11

yacy.net

Check out replies by zkSNARK and stale2002 (just down-page at time of writing). Screen cap here for reference: http://imgur.com/a/xBJUW

But its still the wrong explanation. Think about it:

(i) Miners, not average users, hold the voting power.

(ii) When the 1 MB block-size is congested (like it is now), miners make significantly more money on transaction fee's.

(iii) Increasing the block-size increases supply and reduces demand for priority processing in the block, hence, reduces transaction fee's.

Which explanation truly matches your view of reality here. People (miners) are motivated by "A shared vision" or a dollar in the bank account? Look at it closer (quote from parent comment):

>

> "larger blocks means more resources required to transmit, validate and store blocks and if you cannot validate blocks, then you are trusting transaction validators (miners)"

>

Can you see the problem with the explanation now? Its written from the view of an end user (of bitcoin), not a miner. But its miners who vote on the fork, hence, the above quoted text is mostly irrelevant to understanding the "WHY" of the fork battle.

>I think "you can't block GMail" here is meant in the sense that "you can't block the Google crawler". It's certainly technically trivial to do so, but the opportunity cost from lost users will be, for most businesses, unacceptably high.

Excellent interpretation. Gmail = Google crawler. I've made a note of this now.

What needs to happen next is a deep discussion between yourself and logicallee, in the context of Google crawler as well as how to make gmail come further out of the dark ages with high entropy and no security obscurity.

> if Google implemented my suggestion they could never be blacklisted

Google seems to have built their brand intentionally to be the opposite of what you're asking for though; and absolutely they could be blacklisted with a simple "GMAIL ADDRESSES NO LONGER ACCEPTED HERE".

>which already works but is security through obscurity.

I'm not sure which one you are saying is security through obscurity here... blah+real.id@gmail.com... or the high entropy mkKAjgsdf788hf87hf@gmail.com, both are obscure, but its a stretch of imagination to start labelling this a security issue.

>The webpage also says, "Redundancy is achieved through the use of erasure codes so that your data can always be recovered even in the event of large network outages."

>Does this means files can't be lost, as long as you keep paying your bill?

The white-paper mentions:

>"ORC will soon implement client-side Reed-Solomon erasure coding (Plank (1996)). Erasure coding algorithms break a file into k shards, and programmatically create m parity shards, giving a total of k + m = n shards".

So at first glance its seems like the usenet parchive/PAR2 redundancy methodology, but storing the parity shards locally (client side). Well that's my interpretation of this section of the white-paper anyways.

So in short: it certainly doesn't mean that the files "can't be lost", but it means the owner of the files can rebuild the files using parity shards from client side in that case that network outages affect file availability.

> 2. When something is free, then YOU are the product.

Debian Linux, Firefox, gcc, visual studio... The list goes on. I think the "you are the product" quip has become an overplayed meme of late. Mutually beneficial / co dependence and such themes are more applicable in more cases than not when it comes to free products and services, in my own view anyways.

User ruytlm has posted links to hacker factor blog, and it seems some sophisticated scanners (e.g., Eddie) were crashed by the exploit. In that blog the author postulates that Eddie is a nation-state level (not script kiddie) scanner, so I'd say that the answer to this question will be in your definition of naive. It's tempting to qualify any scanner which crashes on this as naive though, I'd agree. Especially moving forward with the publicity of this post/topic.

Well actually from memory the author of the blog was doubtful if this exploit actually crashed Eddie or not, but it did crash the other bots (Eddie V1 did go offline, possibly as a crash), so it would appear you are correct. Only truely naive bots might well be affected by this.

> Wouldn't all but the most naive scanners use time-out settings, maximum lengths on bytes read etc?

It wouldn't save a scanner from crashing to use a time-out or max read bytes. The defense can send the 100kb zipped data in a matter of seconds. The client then decompresses the zipped data which expands to gigabytes, causing crashes by out-of-memory.

Oh this seems quite an interesting experiment. Curious though if this defence poses no additional risks (beside bandwidth) on the server. I mean, is there any significant chance that the random data could cause a glitch on the server implementation?

Very interesting read indeed. I've a question about it; the article is about defeating malicious crawlers/bots affecting a TOR hidden service, so my question is, how might the author differentiate bot requests from standard client requests on a request-by-request basis? I mean, can I assume that many kinds of requests arrive at hidden service through shared/common relays? Would this mean other fingerprinting methods (user agent etc) would be important, and if so, what options remain for the author if the attackers dynamically change/randomise their fingerprint on a per-request basis?

Could the head be spoofed in such a way that the header says 1MB, or might the clients/bots be typically strict on ensuring header values are valid? I think your raised issue is important though, and any serious client/bot should be ignoring files with 1KB -> 1GB decompression ratios.

After searching the definition of one-time-pad, I'm pretty sure post is redundant and shall be deleted (in T-minus 2 minutes). [edit] No delete option. Mod please delete.

>Assuming that I can exchange keys of some sort (physical, digital) with the other contact.

Each contact has an identical table of data (pure-random, 1 terabyte, ASCII 256 or choose your own encoding); this is your "Key of some sort". Messages sent between contacts are encoded character-by-character as offsets from the start of the table. No offset can be used more than once. After offset 1099511627776 (for a 1 terabyte files) has been used for encode, a new key file is generated and exchanged.

Example:

tables contains a terabyte of random data such as "ahx Ui D 7gu3a7NrdMr 9y&S )iM AAt 8'9s 98m..e kj j uhbd f..."

1,5,6,9,12,15,18,20,23,25,30,33,35,36,39,41 = hi garry it's me

Hi Saurik, my reasoning was obviously not very well researched; actually I can see its a damaging assumption for the PR of jailbreaking when I (or the public in general) makes assumptions that jailbreaking is strongly linked to game piracy, so its appreciated you were able to clarify.

I personally have held my iPad back on iOS 9 for the reason that maybe some day I could jailbreak and install another OS, home brew apps etc. but I made a generalization about piracy I guess because I did see a bunch of demand for that in 2010-2012 which shows you how out of date my iOS knowledge is (since I have not jailbroken any devices between then and now). By the way, thanks for Cydia :) its synonymous in my mind for any discussion about jailbreaking and iOS.

I just think there is some demand for jailbreaking, and lack of public demand isn't a significant explanation for lack of jailbreaking progress on iOS 10/11. I mean, there is no clear argument I've seen yet which establishes a link between public demand and frequency of jailbreaks; after all it only takes a single determined developer/hacker to craft an exploit and deploy it for reasons not connected to public demand.

>but also lack of demand

Unlikely. The demand for pirated material (games) has not diminished. Also its hard to explain why the iPhone suddenly lacks demand for jailbreak when the Android modding community still thrives.

>These days, I think most users are generally happy with the status quo

Jailbreaking was not a thing for most users.

You've been away from HN a few days? The SHA-1 collision example uses PDFs in its demo. Hence other commenter saying SHA 256

The most useful app on this hand-curated list has got to be "how many people in space right now". I mean, who knew it would be 6 ! /s /thread.