From: Jeremy Spilman <jeremy@taplink•co>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] "network disruption as a service" and proof of local storage
Date: Fri, 27 Mar 2015 11:40:43 -0700 [thread overview]
Message-ID: <2B8DBE05-E38E-433F-A4D2-A6D93D2FD4AA@taplink.co> (raw)
In-Reply-To: <2210650.iUsfZECcCc@crushinator>
> On Mar 27, 2015, at 8:16 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:
>
> Isn't the goal of this exercise to ensure more full nodes on the network?
Basically we're talking about a form of Sybil defense and better quantifying true blockchain resiliency by proof of storage.
In this case the goal is to see if we can prove the number of distinct digital copies of the blockchain. This is actually a tricky problem because it will (always?) devolve to inferences from response timing, and we are running over a heterogenous network with heterogeneous machines.
It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost.
I think while its a difficult cost-benefit analysis, even code complexity aside, it's interesting to discuss all the same!
Simply having many unique IP addresses possibly accessing the same unique copy provides a different (if any) benefit. E.g. Tor uses IPs as a cost factor, but (until recently?) didn't even factor in things like them all being the same Class C.
next prev parent reply other threads:[~2015-03-27 18:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 20:01 [Bitcoin-development] Criminal complaints against "network disruption as a service" startups Justus Ranvier
2015-03-13 21:48 ` Mike Hearn
2015-03-13 22:03 ` Justus Ranvier
2015-03-13 22:08 ` Mike Hearn
2015-03-13 22:16 ` Justus Ranvier
2015-03-13 22:24 ` Mike Hearn
2015-03-13 22:38 ` Justus Ranvier
2015-03-16 8:44 ` Jan Møller
2015-03-16 16:29 ` [Bitcoin-development] "network disruption as a service" and proof of local storage Sergio Lerner
2015-03-24 5:14 ` Jeremy Spilman
2015-03-26 22:09 ` Sergio Lerner
2015-03-26 23:04 ` Matt Whitlock
2015-03-27 14:32 ` Robert McKay
2015-03-27 15:16 ` Matt Whitlock
2015-03-27 15:32 ` Robert McKay
[not found] ` <20150327155730.GB20754@amethyst.visucore.com>
2015-03-27 16:00 ` Matt Whitlock
2015-03-27 16:08 ` Matt Whitlock
2015-03-27 18:40 ` Jeremy Spilman [this message]
2015-04-01 2:34 ` Sergio Lerner
2015-03-16 19:33 ` [Bitcoin-development] Criminal complaints against "network disruption as a service" startups Aaron Voisine
2015-03-23 2:44 ` odinn
2015-03-23 10:06 [Bitcoin-development] "network disruption as a service" and proof of local storage Thy Shizzle
2015-03-28 2:55 Thy Shizzle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2B8DBE05-E38E-433F-A4D2-A6D93D2FD4AA@taplink.co \
--to=jeremy@taplink$(echo .)co \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox