From: Erik Aronesty <erik@q32•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full node "tip" function
Date: Thu, 4 May 2017 09:15:02 -0400 [thread overview]
Message-ID: <CAJowKgKpiqeHAFn+tbZAqH9Oojhm8K+8EcJz9kMoU+qgK0PBHA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQYhi3oqncrNU+26E4JoHHfQMJAyTGtJY-ZD6J9O7NPsQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
> Greg
> The primary result would be paying people to sybil attack the network.
I cannot imagine the benefit to replicating an ip address in this case,
except maybe you think that you would be more likely to be selected as a
peer? But there would be no actual advantage since download peers are
selected based on throughput and actual blocks served.
Also, since this makes the network far more resistant to DDOS attacks, it
has added benefits.
> Luke:
> paying for services is in general a great idea, but one that Bitcoin
> can much better serve once Lightning is in production.
I agree, if lightning networks were baked in, then the tips could be as
granular as "per block downloaded", or even (outlandish seeming now, but
maybe not in a future where there is a "public rpc api") "per rpc call".
Miners and business users would certainly pay for high quality services.
Spinning up new nodes without a tip and relying on the "free network" would
probably take more time, for example.
I suspect that if income were even a small possibility the number of full
nodes would vastly increase.
Sybil attacks seem irrelevant as long as reasonable QOS metrics are stored
per peer.
On Wed, May 3, 2017 at 5:53 PM, Gregory Maxwell <greg@xiph•org> wrote:
> On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > CONS:
>
> The primary result would be paying people to sybil attack the network.
> It's far cheaper to run one node behind thousands of IPs than it is to
> run many nodes.
>
> Suggestions like this have come up many times before.
>
[-- Attachment #2: Type: text/html, Size: 2190 bytes --]
next prev parent reply other threads:[~2017-05-04 13:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 21:08 Erik Aronesty
2017-05-03 21:43 ` Ben Thompson
2017-05-04 10:38 ` Tomas
2017-05-04 13:37 ` Aymeric Vitte
2017-05-04 13:47 ` Erik Aronesty
2017-05-04 14:31 ` Aymeric Vitte
2017-05-03 21:53 ` Gregory Maxwell
2017-05-03 22:03 ` Matt Corallo
2017-05-04 13:15 ` Erik Aronesty [this message]
2017-05-04 14:57 ` Tom Zander
2017-05-03 23:21 ` Luke Dashjr
[not found] ` <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>
2017-05-04 19:28 ` Erik Aronesty
2017-05-08 21:00 ` Sergio Demian Lerner
2017-05-08 21:44 ` Natanael
2017-05-08 22:15 ` Sergio Demian Lerner
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=CAJowKgKpiqeHAFn+tbZAqH9Oojhm8K+8EcJz9kMoU+qgK0PBHA@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/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