MIME-Version: 1.0
In-Reply-To: <CAJowKgLzMZe1RcAW+FYsUZkvdZ5ZFf6cS5oJdZ=0apM0wMXc+g@mail.gmail.com>
References: <CAJowKg+snAUjbCFkTybNqiJCy=d_M3s5k376y1B=rVqD8WCOXA@mail.gmail.com>
	<201705032321.14356.luke@dashjr.org>
	<9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>
	<CAJowKgLzMZe1RcAW+FYsUZkvdZ5ZFf6cS5oJdZ=0apM0wMXc+g@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Mon, 8 May 2017 18:00:10 -0300
Message-ID: <CAKzdR-qbVAiXpuzAa+4VcBrq=h=65A-8ANTN3vOrVCV6fJ7yqQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary=94eb2c075b6cc152d9054f0988b8
Cc: Eric Lombrozo <eric@ciphrex.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full node "tip" function
Precedence: list

--94eb2c075b6cc152d9054f0988b8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A full node provides several services to the network:

1=E2=80=A2Broadcasts blocks (public service)
2=E2=80=A2Broadcasts transactions (public/private service)
3=E2=80=A2Increases privacy by hiding other node=E2=80=99s IPs
4=E2=80=A2Increases network security by protecting it from global DoS.
5=E2=80=A2Provides information filtering services to SPV nodes.
6=E2=80=A2Provides historic blockchain and state information to new nodes.

With your tip idea you only encourages 6, and by increasing the number of
nodes, also 3 and 4.
The services 1 and 2 cannot be encouraged by tips.

However, it's a good way to start.

There was a way to encourage 2 I described in 2013. (
https://bitcointalk.org/index.php?topic=3D385528.msg4155300#msg4155300)

I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS), a feature
that RSK will add to incentivize Bitcoin and RSK full nodes. This solution
encourages 6.


On Thu, May 4, 2017 at 4:28 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is actually LN=E2=80=99s killer use case - not buying coffees ;)
>>
>
> Yes, micro-payments for online network services is precisely what LN is
> best at.
>
> Establishing a channel with each peer is too expensive.   But using LN to
> micro-pay for high-quality peer services seems like it would aggregate ve=
ry
> well.
>
> It would be great if this protocol was in-place and ready to go in or
> around the same time LN is ready.   It would incentivize full nodes even
> further than LN does, and allow the network to be strongly DDOS resistant=
.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c075b6cc152d9054f0988b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A full node provides several services to the network:<div>=
<br></div>1=E2=80=A2Broadcasts blocks (public service)<br>2=E2=80=A2Broadca=
sts transactions (public/private service)<br>3=E2=80=A2Increases privacy by=
 hiding other node=E2=80=99s IPs<br>4=E2=80=A2Increases network security by=
 protecting it from global DoS.<br>5=E2=80=A2Provides information filtering=
 services to SPV nodes.<br>6=E2=80=A2Provides historic blockchain and state=
 information to new nodes.<br><div><br></div><div>With your tip idea you on=
ly encourages 6, and by increasing the number of nodes, also 3 and 4.</div>=
<div>The services 1 and 2 cannot be encouraged by tips.</div><div><br></div=
><div>However, it&#39;s a good way to start.</div><div><div><br></div><div>=
There was a way to encourage 2 I described in 2013. (<a href=3D"https://bit=
cointalk.org/index.php?topic=3D385528.msg4155300#msg4155300">https://bitcoi=
ntalk.org/index.php?topic=3D385528.msg4155300#msg4155300</a>)</div></div><d=
iv><br></div><div>I&#39;ll soon present a solution to encourage full nodes =
to store the blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)=
, a feature that RSK will add to incentivize Bitcoin and RSK full nodes. Th=
is solution encourages 6.</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, May 4, 2017 at 4:=
28 PM, Erik Aronesty via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">This is actually LN=E2=80=99s killer use case=
 - not buying coffees ;)<br></blockquote><div><br></div><div>Yes, micro-pay=
ments for online network services is precisely what LN is best at.=C2=A0=C2=
=A0 <br><br>Establishing a channel with each peer is too expensive.=C2=A0=
=C2=A0 But using LN to micro-pay for high-quality peer services seems like =
it would aggregate very well.=C2=A0=C2=A0 <br><br>It would be great if this=
 protocol was in-place and ready to go in or around the same time LN is rea=
dy.=C2=A0=C2=A0 It would incentivize full nodes even further than LN does, =
and allow the network to be strongly DDOS resistant.<br></div></div><br></d=
iv></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c075b6cc152d9054f0988b8--