summaryrefslogtreecommitdiff
path: root/19/638147467d0c1128f5a8053a1b0386b2569577
blob: 8497c0077d67b17e7411f80edce49ff9975ecf17 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6893172A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 May 2017 21:00:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A37818F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 May 2017 21:00:53 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id u75so63246362qka.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 08 May 2017 14:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=x8iuDSG6RoWXVWAAeb698Z4SuhddCMIk3TMwewq2AM4=;
	b=Agc8diGG98PEya2hk3E17ee77/6d6carIJcvuw9kwflA80KCs0t2lJxyHPTbOAU77F
	gGgO9zkWd0VeqYVzRfY/PxfbSVH/jB+DSrfhLPdBXxqkI8HIfbV5dFEFPcPdDXMZAEzf
	IsTPbTfE78VC6f5bhn2pMvHVuCe+poD4plUjHEtSSNGgFkLJQ1jTJ98NT5vqrTcmsHJa
	t+onY5JmdQPPHl+3Fq4ZbFxfTwhEkMWDqYiRSrDv8UlXN62K/klYLXGG1Tp06Vj/JNoi
	y1laNtNN/sDKaHHH/4Jh0m4xd7hS5qTjCtb/g5BFHMqEyikM3wF+0/tqKkMibBffXH5Y
	pQoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=x8iuDSG6RoWXVWAAeb698Z4SuhddCMIk3TMwewq2AM4=;
	b=tFQIiV8/rQ8ZEiVCd7fklDYGHXgVHuBZIgrkIXmqTw2U3T9MiFkH99Kxuo8J1zSakI
	d6uI4izP4mipijQqT6QYWgafQ+GDmHRf0B5LRnw8QIzbQbo+GYEvcDpnWfv7Oj320qX0
	Mxy6yhRySDhLb7T11XQisW2wLw9e2Q+eiScfvblm+a3Vgw7XqLhH0hZzUCWy6/ZmUlrN
	tSnPh027aXUE0Za4ho8myL3F5v2IRMX6Mgq3OFi0ByrCAtqczGPjZuQmXAffaRIfXI38
	1H5kBxOdtIbEc0kf5oWp7q4XjEAPKWHoZHF/MMd+T4JSflYcNCcol/HV5ZfynO0hOpbC
	5oYg==
X-Gm-Message-State: AODbwcCmoh/prkjkSqpii3zq2NdyN1RNcRro4ub6pMbxj1a3Pb0GdgoN
	zWlZwefqQC0CP7wi0lJgkd/lll/sDw==
X-Received: by 10.55.163.20 with SMTP id m20mr30059741qke.265.1494277251222;
	Mon, 08 May 2017 14:00:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.165.132 with HTTP; Mon, 8 May 2017 14:00:10 -0700 (PDT)
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
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Eric Lombrozo <eric@ciphrex.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full node "tip" function
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2017 21:00:54 -0000

--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--