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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zellfaze@yahoo.com>) id 1ReeF2-0003uk-GE
for bitcoin-development@lists.sourceforge.net;
Sun, 25 Dec 2011 02:55:16 +0000
X-ACL-Warn:
Received: from nm9-vm4.bullet.mail.ne1.yahoo.com ([98.138.91.169])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1ReeF0-0002cB-5L for bitcoin-development@lists.sourceforge.net;
Sun, 25 Dec 2011 02:55:16 +0000
Received: from [98.138.90.52] by nm9.bullet.mail.ne1.yahoo.com with NNFMP;
25 Dec 2011 02:55:09 -0000
Received: from [98.138.87.7] by tm5.bullet.mail.ne1.yahoo.com with NNFMP;
25 Dec 2011 02:55:08 -0000
Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP;
25 Dec 2011 02:55:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 791181.16444.bm@omp1007.mail.ne1.yahoo.com
Received: (qmail 61587 invoked by uid 60001); 25 Dec 2011 02:55:08 -0000
X-YMail-OSG: _ZYq76IVM1nSuiBrJUG1X3MLHsBoMp81MkDSZFN01ZQJIgg
r9Wi1K6YlRrdhQZ7nuKvEPJkGD3SOrNiya87g2GAcDkguh9xq5OiDEbpbnRw
W_9tG30vKPBf0z7Ds18CVGI6tHBj1upltLYvH2RS5fbyfYW_PpE26EXebBju
wqBIEgoHww.Q4XFci6re1ye25Sg9ZbdjenC3IapvCVsOq4iCc..LXuFd6h1E
o6gssYNw9EnB1xMzuvmn._ehBcqadbntYdZOJM0812H_0tF1Q5zhaKaYAKcl
WdP94vKvNWEMqN_kVkVlhvarOL.qxGGIPitnSIRlVsrYQj4KEihCjd4miFRJ
xawLti6hFHrAVyFVZFIPgDHIBm4q198TqbTDVLqlL2Clt1fnO7FLrgTvJIIh
gll3kxld1UO2sgVxVhDEeHUAdAdyWWKqfEg8rtv6Hne592tyKWtjW9cZ.rys
5fFpfdlv7llw8E6v0QLvBNbxooKKxZhJLE8UglAHF5RD.IH90MafxW3d2eEz
F.nm.WqgHg_p30XOviz4DDHdIen5FeN2Ph01h673iZT_12hbOW7_bSV4Pixa
esId0N9aLjw--
Received: from [108.8.7.210] by web120905.mail.ne1.yahoo.com via HTTP;
Sat, 24 Dec 2011 18:55:08 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.115.331698
Message-ID: <1324781708.61136.YahooMailClassic@web120905.mail.ne1.yahoo.com>
Date: Sat, 24 Dec 2011 18:55:08 -0800 (PST)
From: Zell Faze <zellfaze@yahoo.com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>,
Andy Parkins <andyparkins@gmail.com>
In-Reply-To: <201112221446.54526.andyparkins@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(zellfaze[at]yahoo.com)
-2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [98.138.91.169 listed in list.dnswl.org]
2.5 FREEMAIL_REPLY From and body contain different freemails
-1.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1ReeF0-0002cB-5L
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 25 Dec 2011 02:55:16 -0000
I may be missing something, but perhaps the simplistic method is the best. =
=0A=0AStart all nodes off with a certain level of trust. Lets choose an a=
rbitrary number 5.=0AIf a node's trust level is high enough (lets say 10) f=
orward transactions it sends you without checking them.=0AIf a node's trust=
level is low enough (lets say 0) discard any transactions they send you (i=
.e. don't forward them on).=0AFor nodes with a trust level between 1 and 9,=
forward without checking between 1 and 9 out of every 10 transactions. Ch=
eck the others, if they are valid, increase the trust level by 1, if they a=
re invalid decrease the trust level by 3.=0A=0AAll of the numbers mentioned=
here (1-10, 1, 10, 1, 5, and 3) are arbitrary numbers that should be deter=
mined by the client or user-preferences instead of the protocol. This woul=
d allow for clients to have varying amounts of initial trust/paranoia about=
their peers.=0A=0ABy decreasing the amount of trust faster than we increas=
e it, we make it harder for untrustworthy clients to cheat us. By having a=
cut off point, we make it so that untrustworthy clients can not DDoS us. =
By randomly verifying some transactions in the beginning, we make it harder=
for a new client from DDoSing us, and we prevent our own trust level from =
being hurt too much for forwarding on invalid transactions.=0A=0AThe only p=
roblem I can personally see with this system is that if Node A trusts Node =
B with a 10 and Node C connects to Node A, then Node C can send transactio=
ns that are invalid to Node C via Node A without Node C being any the wiser=
. This would be stopped fairly quickly as Node B would catch on and stop f=
orwarding transactions, but it would be a problem for new Nodes.=0A=0AThis =
could be fixed (somewhat) by having a message that says not to trust a part=
icular node.=0A=0A--Zell Faze=0A=0A=0A=0A--- On Thu, 12/22/11, Andy Parkins=
<andyparkins@gmail.com> wrote:=0A=0A> From: Andy Parkins <andyparkins@gmai=
l.com>=0A> Subject: Re: [Bitcoin-development] Protocol extensions=0A> To: "=
Joel Joonatan Kaartinen" <joel.kaartinen@gmail.com>=0A> Cc: bitcoin-develop=
ment@lists.sourceforge.net=0A> Date: Thursday, December 22, 2011, 9:46 AM=
=0A> On 2011 December 22 Thursday, Joel=0A> Joonatan Kaartinen wrote:=0A> >=
On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins=0A> wrote:=0A> > > Why sho=
uld they have to?=A0 Joining the=0A> network as a node is very low cost=0A>=
> > to the other nodes.=A0 You can't force any=0A> node not to be lazy, si=
nce=0A> > > their option is to disconnect themselves.=A0=0A> As to maliciou=
sness, that is=0A> > > defended against because when a node negative=0A> an=
nounces a transaction,=0A> > > that transaction is going to be checked (not=
e=0A> that there is still no=0A> > > implicit trust) -- if a node is incorr=
ectly=0A> negative-announcing then it=0A> > > can justifiably be kicked.=0A=
> > =0A> > a node that is not doing any checking themselves can=0A> not rel=
iably=0A> > forward failed verifications without getting the blame=0A> for =
doing faulty=0A> > work. Those nodes would then have the incentive not to=
=0A> relay the failed=0A> > verifications. This ends up making it important=
to=0A> know which nodes will=0A> > be checking transactions or not so you =
don't isolate=0A> yourself from other=0A> > nodes that are also checking tr=
ansactions.=0A> =0A> Yes; I appreciate that.=A0 It's the very point I'm=0A>=
making.=A0 A node can choose =0A> what work to do, and should have a way o=
f forwarding the=0A> results of that work =0A> to other nodes.=A0 Transacti=
on verifification is the=0A> main one.=0A> =0A> Once a negative-announce me=
ssage exists, it wouldn't be=0A> hard to have the other =0A> two you need a=
s well: positive-announce and=0A> neutral-announce.=A0 At present we =0A> h=
ave only neutral-announce.=A0 However, as the need for=0A> super nodes and =
=0A> distributed verification gets bigger, having the forwarder=0A> able to=
offer an =0A> opinion on the quality of a transaction seems ideal to=0A> m=
e.=A0 Dishonesty will =0A> get you isolated pretty quickly if you use=0A> p=
ositive-announce and negative-=0A> announce to lie.=0A> =0A> The problem wi=
th this is that it requires a web of trust as=0A> well as a web of =0A> con=
nections.=A0 The only way to gain an advantage from=0A> this classified =0A=
> forwarding is if you have some way of assigning enough=0A> trust so that =
you can =0A> forward a classified transaction _without_ checking it=0A> you=
rself.=A0 That doesn't =0A> sound like an easy problem though.=0A> =0A> =0A=
> =0A> Andy=0A> =0A> -- =0A> Dr Andy Parkins=0A> andyparkins@gmail.com=0A> =
=0A> -----Inline Attachment Follows-----=0A> =0A> -------------------------=
-----------------------------------------------------=0A> Write once. Port =
to many.=0A> Get the SDK and tools to simplify cross-platform app=0A> devel=
opment. Create =0A> new or port existing apps to sell to consumers worldwid=
e.=0A> Explore the =0A> Intel AppUpSM program developer opportunity.=0A> ap=
pdeveloper.intel.com/join=0A> http://p.sf.net/sfu/intel-appdev=0A> -----Inl=
ine Attachment Follows-----=0A> =0A> ______________________________________=
_________=0A> Bitcoin-development mailing list=0A> Bitcoin-development@list=
s.sourceforge.net=0A> https://lists.sourceforge.net/lists/listinfo/bitcoin-=
development=0A>
|
