Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Looking for Feedback | Ombuds

Nick Skelsey nskelsey at gmail.com
Tue Aug 25 09:22:58 PDT 2015


Steve,

My responses are inline. Thanks for the questions!

On Tue, Aug 25, 2015 at 11:35 AM, Steve Weis <steveweis at gmail.com> wrote:

> Hi Nick. I'll throw out some questions:
> - The Bitcoin blockchain is 40GB and growing at about 4GB a month.
> Will end users have to download that much data to their clients? Or
> will people be able to download a partial chain? If the latter, will
> this have to rely on trusted intermediaries?
>

I expect a subset of users to download the entire block chain. These people
or organizations then become the trusted intermediaries to a complete view
of content stored within. Users of mobile clients can do what Bitcoin
mobile clients do and have a partial (and only personal) view of the entire
record [Section 4.2]. Additionally, the headers of Bitcoin blocks end up
only taking up around 4MB per month and that is enough to ensure what you
have written is stored in the record.


> - If an entity has enough control over a network to censor, can they
> split the network and control their own fork of the chain? What
> happens if an entity decides to restrict access to the blockchain?
> Section 5.3 on "Potemkin networks" touches on this. The only answer
> given is that a peer will have to somehow pull down data from the
> trunk of the blockchain.
>

Yes, a malicious entity can fork the chain, but not forever. If they have
enough hash-power to mount a 51% attack on the entire network, then they
can arbitrarily include and exclude statements. The nice thing about
Bitcoin is that if that entity does not have control over that much hash
power, then the honest chain will always be the 'best' chain. This means
that if somebody can walk across a border with a usb stick or find some
other way to stream the data, they can manually import the chain and
distribute the real record to their peers.

This answer and I am not sure if this is right, assumes that the packet
filtering to segment a network exists at its edges and not internally. Or
at least that is not effective against a local peer-to-peer network.


> - Users of Omsbud will have distinctive traffic patterns. Do you need
> to assume enough Bitcoin adoption that using it won't be a red flag?


It will be a red flag if you just switch it on and we won't misrepresent
that. We assume that a user in a scenario where this level of analysis is
employed is using something like Tor to anonymize and obfuscate their
traffic anyway. We want Ombuds to be the end point that a person reaches
out to when they do find a secure connection out.


> On Tue, Aug 25, 2015 at 8:01 AM, Nick Skelsey <nskelsey at gmail.com> wrote:
> > I am bumping this post just once.
> >
> > I was hoping to see if anybody had any "hold on" kind of thoughts before
> we
> > continue on our merry way building this system out. We are working to
> create
> > a free public record for the Internet via user submitted statements. Any
> > bits of wisdom you have helps!
> >
> >
> > On Wed, Aug 19, 2015 at 2:41 PM, Nick Skelsey <nskelsey at gmail.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> A friend and I have been working on (yet another) anti-censorship tool
> and
> >> we are getting ready to release it. The tool is kind of like a BBS, but
> the
> >> interesting thing about it is that all public statements made through
> it are
> >> stored in a block chain. This is in contrast to a traditional
> microblogging
> >> service where the site's operator has control over a user's content. In
> our
> >> case, we use Bitcoin's block chain.
> >>
> >> I am soliciting questions, comments, and concerns about the design
> before
> >> we try to get anyone to use the tool seriously. You can read more about
> the
> >> design, how we plan to scale it, and some attacks we foresee in our
> paper
> >> [1]. Feel free to checkout the software [2] and the rest of our material
> >> online [3]. None of it is really finished, but we welcome all criticism.
> >>
> >>   Nick
> >>
> >> [1] https://getombuds.org/research/
> >> [2] https://github.com/soapboxsys/OmbudsCore
> >> [3] https://relay.getombuds.org
> >
> >
> >
> > --
> > Liberationtech is public & archives are searchable on Google. Violations
> of
> > list guidelines will get you moderated:
> > https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe,
> > change to digest, or change password by emailing moderator at
> > companys at stanford.edu.
> --
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20150825/e8ab3dca/attachment.html>


More information about the liberationtech mailing list