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
178
|
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F27F6B62
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2017 10:38:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1126F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2017 10:38:30 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id 39DD520A5D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2017 06:38:30 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Thu, 04 May 2017 06:38:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4XrVkN
nJf6yW1arAF/C3zCRIoq88gWdbqmEOahutTz4=; b=RZOHSpKui2npFoeUJ9wSXT
bifRlUzmBM2moSelLVtgm9AmZGR5NbMQNnZptyBpdy9qZVfMFG8mSXRqfxJGxaSg
kDtfxqZiQdqlYKB/V5nQRhrBklukigidboeSczWJI879kGATiH+akIBkmLcUxcaS
8S+RdjVRxtVJDYFCwdhkg9AXq1xlmKVKLy8dFQaDnENs1HHUE+BxxhbPTQUePCyW
Cn/OfnCh/f0FY8ERjdQp4jDNfKrxBec18jHkJ2lbmR7ZOhOI/0LOscRde5F1871z
M13OIjaXrFJh/C9gBV8Eq2fXbw081OCxdmC8OcMFA0/E+AQj7prgIFG9toQbPo2w
==
X-ME-Sender: <xms:pgQLWX0hrah-7e_ACbIPKijbkfZYhRF2zFmVshbHDlzKuLsh2Igrmg>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id 154B49EBDF; Thu, 4 May 2017 06:38:30 -0400 (EDT)
Message-Id: <1493894309.1179269.965498864.6244705A@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_149389431011792690"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1
References: <CAJowKg+snAUjbCFkTybNqiJCy=d_M3s5k376y1B=rVqD8WCOXA@mail.gmail.com>
<CAOxie=GNQtoJLEoY=aHGT5m1RFFmrqVi5p6BMnT-sRkHjkhGcw@mail.gmail.com>
Date: Thu, 04 May 2017 12:38:29 +0200
In-Reply-To: <CAOxie=GNQtoJLEoY=aHGT5m1RFFmrqVi5p6BMnT-sRkHjkhGcw@mail.gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 04 May 2017 12:39:45 +0000
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: Thu, 04 May 2017 10:38:32 -0000
This is a multi-part message in MIME format.
--_----------=_149389431011792690
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
The ones that *could* pay non-mining full nodes are miners/pools, by
outsourcing transaction selection using a different PoW. By doing so
they could buy proof-of-uncensored-selection and proof-of-goodwill for a
small fee.
We would allow full nodes to generate and broadcast a template
block which:
* Does not contain a valid header yet
* Contains the transaction selection
* Contains a coinbase output with a predetermined part of the block
reward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined currently ASIC resistant
hash function behind a OP_RETURN.
The template with the highest PoW since the last block would be leading.
A miner/pool can then choose to use this instead of their own, adding
the rest of the reward and the SHA nonce themselves. That way they would
set up a competition among full nodes.
This would of course be voluntary but provable, so maybe in a pool's
interest to do this via naming and shaming.
Tomas
bitcrust
On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
> I feel like this would be pointless as the vast majority of users
> would likely download the blockchain from a node that was not
> enforcing a tip requirement as it would seem like unnecessary cost as
> in protocols such as BitTorrent there is no such tips in sharing files
> and the blockchain distribution is in eccense the same thing. However
> perhaps I am underestimating the generosity of node operators but I
> feel that adding a cost to the blockchain (assuming that all users add
> a tip requirement) would lead to centralisation.>
> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev, <bitcoin-
> dev@lists.linuxfoundation.org> wrote:>> IDEA:
>> - Full nodes advertise a bitcoin address. Users that need to
>> download the block chain from that node can be encouraged to send a
>> tip to the peers that served them (by % served). Recommended tip
>> of 10mbit should be fine.>>
>> - A full nodes can *require* a tip to download the blockchain. If
>> they do, users that don't specify a tip cannot use them.>>
>> CONS:
>>
>> For some people, this may represent a barrier to hosting their own
>> full node. After all, if you have to pay $15 just to get a copy of
>> the blockchain, that just adds to the already expensive prospect of
>> hosting a full node.>> PROS:
>>
>> As long as you manage to stay online, you should get your money back
>> and more. This is the an incentive for quality, long term hosting.>> In the long term, this should cause stable nodes to stick around
>> longer. It also discourages "installation spam" attacks on the
>> network.>> Fees for other node operations can be considered if this is
>> successful.>>
--_----------=_149389431011792690
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="utf-8"
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>The ones that *could* pay non-mining full nodes are miners/pools, by outsourcing transaction selection using a different PoW. By doing so they could buy proof-of-uncensored-selection and proof-of-goodwill for a small fee.<br></div>
<div><br></div>
<div>We would allow full nodes to generate and broadcast a template block which:<br></div>
<div><br></div>
<div>* Does not contain a valid header yet<br></div>
<div>* Contains the transaction selection<br></div>
<div>* Contains a coinbase output with a predetermined part of the block reward (say 0.5%) to themselves<br></div>
<div>* Contains a nonce for PoW of a predetermined currently ASIC resistant hash function behind a OP_RETURN.<br></div>
<div><br></div>
<div>The template with the highest PoW since the last block would be leading. A miner/pool can then choose to use this instead of their own, adding the rest of the reward and the SHA nonce themselves. That way they would set up a competition among full nodes.<br></div>
<div><br></div>
<div>This would of course be voluntary but provable, so maybe in a pool's interest to do this via naming and shaming.<br></div>
<div><br></div>
<div>Tomas<br></div>
<div>bitcrust<br></div>
<div><br></div>
<div>On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:<br></div>
<blockquote type="cite"><div dir="ltr">I feel like this would be pointless as the vast majority of users would likely download the blockchain from a node that was not enforcing a tip requirement as it would seem like unnecessary cost as in protocols such as BitTorrent there is no such tips in sharing files and the blockchain distribution is in eccense the same thing. However perhaps I am underestimating the generosity of node operators but I feel that adding a cost to the blockchain (assuming that all users add a tip requirement) would lead to centralisation.<br></div>
<div><span></span><br></div>
<div><div dir="ltr">On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev, <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div><div><div><div>IDEA:<br></div>
</div>
<div>- Full nodes advertise a bitcoin address. Users that need to download the block chain from that node can be encouraged to send a tip to the peers that served them (by % served). Recommended tip of 10mbit should be fine.<br></div>
<div><br></div>
</div>
<div>- A full nodes can *require* a tip to download the blockchain. If they do, users that don't specify a tip cannot use them.<br></div>
<div><br></div>
</div>
<div><div>CONS:<br></div>
<div><br></div>
<div>For some people, this may represent a barrier to hosting their own full node. After all, if you have to pay $15 just to get a copy of the blockchain, that just adds to the already expensive prospect of hosting a full node. <br></div>
</div>
<div>PROS: <br></div>
<div><div><br></div>
<div>As long as you manage to stay online, you should get your money back and more. This is the an incentive for quality, long term hosting.<br></div>
</div>
<div><div>In the long term, this should cause stable nodes to stick around longer. It also discourages "installation spam" attacks on the network.<br></div>
</div>
<div>Fees for other node operations can be considered if this is successful.<br></div>
<div><div><br></div>
</div>
</div>
</blockquote></div>
</blockquote><div><br></div>
</body>
</html>
--_----------=_149389431011792690--
|
