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
|
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E5A83938
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 12:44:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75C48F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 12:44:05 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so2353336lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 05:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=bJAaIkDrM7AvWfy06XNnGmj9SZxdhs5ymPgtNz/zV5I=;
b=G+fCEEvQ1WuspZibJb6xbahaJWcwnW4fn/QD/HU+TqtkNU3/+rU0hgdVOZh1Z9/I3U
L4q9WmdTt4vtsnjsx7YwDE6GrG2HTXCPX8AHrJ83Zwum3GgFMZYntrhe8u1kfFM5i9xE
2TcE6UiiEmV14zeeHaKqutH0r+J0cVZXqysMutHboK96ZyUAKzP2XdbB76twZ4IDM4iY
7xksLQceCyEyEmdMk+3wVCd74JXxWr9qCCIgDJ+vnkzvFttiyKU98aAO+wO42tobV0uQ
2yzgJ/LGa1yHWyzCyIuQeY23j744Zlzf8kLvIX3h3v/Tmz1XTZttgXFl1+8brLJrnknh
KXuw==
MIME-Version: 1.0
X-Received: by 10.152.87.227 with SMTP id bb3mr438012lab.1.1439988243980; Wed,
19 Aug 2015 05:44:03 -0700 (PDT)
Received: by 10.25.150.84 with HTTP; Wed, 19 Aug 2015 05:44:03 -0700 (PDT)
In-Reply-To: <CAAO2FKHG1PHKjMw7ER=w-MgS7uNY_NLgzFM0aVKqP+BRUZOw9g@mail.gmail.com>
References: <CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com>
<CADL_X_duSHosyMAfOXPv7WcWKTY19Q2i+_zFSuuGbGantbbmRw@mail.gmail.com>
<CAAO2FKE44WqJOEaR2TYRwzAsPQxh7Z1K3esQiMFsSsk2+65-4w@mail.gmail.com>
<CADL_X_dUd2MLt_P5+o=uS+LP_12ybRTGeq1WQzQY2m6kf6qtDA@mail.gmail.com>
<CAAO2FKHG1PHKjMw7ER=w-MgS7uNY_NLgzFM0aVKqP+BRUZOw9g@mail.gmail.com>
Date: Wed, 19 Aug 2015 08:44:03 -0400
Message-ID: <CADL_X_f5WZOQF==1LiBkX=kLO+9dGb1mxu__6Mu_b1WqR20hYA@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Hector Chu <hectorchu@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2ae9cc36784051da963df
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A solution to increase the incentive of running a
node
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 19 Aug 2015 12:44:07 -0000
--001a11c2ae9cc36784051da963df
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu <hectorchu@gmail.com> wrote:
> On 19 August 2015 at 13:08, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I understand it. My proposal requires nodes to
> validate transactions that are unconfirmed, and to commit to the
> validation by doing a POW on it.
>
> It's possible to check that a transaction is cryptographically valid
without having any blockchain data available; are you referring to a
different type of validation?
If you're running an SPV node that is listening to full nodes on the
network, you can request an unconfirmed transaction from connected peers
after receiving the inventory message they send - that's how unconfirmed
transactions propagate through the node network. This is not 100% proof
that the transaction is valid for inclusion in the blockchain, but it's a
very good indicator.
- Jameson
> > On an unrelated note, it sounds like your proposal will significantly
> > increase the data size of every transaction, which will create even more
> > contention for block space.
>
> If we stipulate that the coinbase fields only hold space for a single
> pubkey, then the entire block header including the two coinbases
> should only take an extra 100 bytes or so. Transactions are already
> routinely 250 bytes+. So an increase of roughly 33%.
>
--001a11c2ae9cc36784051da963df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu <span dir=3D"ltr"><<a href=
=3D"mailto:hectorchu@gmail.com" target=3D"_blank">hectorchu@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 19 A=
ugust 2015 at 13:08, Jameson Lopp <<a href=3D"mailto:jameson.lopp@gmail.=
com">jameson.lopp@gmail.com</a>> wrote:<br>
> If operating as an SPV node then it can check the transactions by quer=
ying<br>
> other nodes.<br>
<br>
</span>SPV is for checking validity of transactions that have already enter=
ed<br>
the blockchain, as I understand it. My proposal requires nodes to<br>
validate transactions that are unconfirmed, and to commit to the<br>
validation by doing a POW on it.<br>
<span class=3D""><br></span></blockquote><div>It's possible to check th=
at a transaction is cryptographically valid without having any blockchain d=
ata available; are you referring to a different type of validation?<br><br>=
</div><div>If you're running an SPV node that is listening to full node=
s on the network, you can request an unconfirmed transaction from connected=
peers after receiving the inventory message they send - that's how unc=
onfirmed transactions propagate through the node network. This is not 100% =
proof that the transaction is valid for inclusion in the blockchain, but it=
's a very good indicator.<br><br></div><div>- Jameson<br></div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
> On an unrelated note, it sounds like your proposal will significantly<=
br>
> increase the data size of every transaction, which will create even mo=
re<br>
> contention for block space.<br>
<br>
</span>If we stipulate that the coinbase fields only hold space for a singl=
e<br>
pubkey, then the entire block header including the two coinbases<br>
should only take an extra 100 bytes or so. Transactions are already<br>
routinely 250 bytes+. So an increase of roughly 33%.<br>
</blockquote></div><br></div></div>
--001a11c2ae9cc36784051da963df--
|
