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
179
180
181
182
183
184
185
186
187
188
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kb@karelbilek.com>) id 1WwyRW-0006Z7-JI
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 18:49:14 +0000
Received: from mail-qc0-f170.google.com ([209.85.216.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwyRU-0005Nx-TL
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 18:49:14 +0000
Received: by mail-qc0-f170.google.com with SMTP id l6so10669533qcy.29
for <bitcoin-development@lists.sourceforge.net>;
Tue, 17 Jun 2014 11:49:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type:content-transfer-encoding;
bh=sbCEBhQiI5q1lTxLXKOb9C6CES1+MTzDg98VUTq8/cc=;
b=ZEUkX4TGxPxTtBlCeNsmhvPO6P0LC1n2bt2aP+yixgJNA/oezvahsoFq7JSs3vYzga
IJ0+l0aGqQUjWWL9pXpPQqp6/PHc36fbk9bifrUBIOHh43CnbwUpBiCehalA3BHP2L3D
VcWjmfoVDvPzXoK7WrQcGiVDswyTVbEHVN3TrQbQNpteaRyJn/Wt2diYKTwGfHLE2kHe
8EuCfgPalEM467qri1BscV3I2Z3k5XRlmw3kJvUijRJaGRsNtSuQRUzXXPC1yOSOTz8x
TE68O1huvF20f6y5TjqUbP2ZEgt5SRtuFvd6ydBv0/C9DC8EAnpw5JidpEQuNINBCbAT
weGQ==
X-Gm-Message-State: ALoCoQmDjGMKfKhfod4Q5c16O5hCYMJCfFfby+90sO1l9E2MjG0txR6IHIcWWxzu/7ySpFe4D5qd
X-Received: by 10.140.104.66 with SMTP id z60mr36129897qge.21.1403029560131;
Tue, 17 Jun 2014 11:26:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.95.101 with HTTP; Tue, 17 Jun 2014 11:25:39 -0700 (PDT)
X-Originating-IP: [78.128.176.71]
In-Reply-To: <CANOOu=9W42upZGtXWvRwyJH0tO766VT37jAR23V_rCZ9+qxTTw@mail.gmail.com>
References: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com>
<CANOOu=9W42upZGtXWvRwyJH0tO766VT37jAR23V_rCZ9+qxTTw@mail.gmail.com>
From: =?UTF-8?B?S2FyZWwgQsOtbGVr?= <kb@karelbilek.com>
Date: Tue, 17 Jun 2014 20:25:39 +0200
Message-ID: <CAGUkT8ZTtR_ysR+0Ufq4k=SLeifEOQYtrak6G_iJRQqc3dt6Jg@mail.gmail.com>
To: Christophe Biocca <christophe.biocca@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WwyRU-0005Nx-TL
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposals for improving Bitcoin mining
decentralization
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: Tue, 17 Jun 2014 18:49:14 -0000
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
<christophe.biocca@gmail.com> wrote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems.
This. There is no need to create anything new when GBT already exists.
In my opinion.
> Unfortunately, it is opt-in,
> and GHash.io doesn't support it.
Yep. As pools in general are not a part of the bitcoin protocol itself
(nobody cares how the work happened), I am not sure how this can be
forced.
> Also most miners don't care and don't do the work to set it up. To do
> transaction inclusion themselves, they'd need to run a full node,
> which is a bit more work and resources than just pointing hashpower at
> a stratum server.
Also, yep. If the miners cared about 51% attack, they wouldn't join
ghash in the first place. All the miners willingly accept the risk in
joining the big pool.
K. B.
> If you figure out a way to make GBT widely used (>50% hashpower), kudos t=
o you.
>
> On Tue, Jun 17, 2014 at 4:57 AM, Ra=C3=BAl Mart=C3=ADnez <rme@i-rme.es> w=
rote:
>> First of all I apologice due to the possible mistakes in my writing belo=
w, I
>> am not a Bitcoin developer but I have some knowledge about it.
>>
>> ----
>>
>> We all know the recent news, Ghash pool controlling 51% of the hashrate.
>> While some consider it a threat others think that is not harmful.
>>
>> The thing is that we have to do something to stop this from happening ag=
ain.
>>
>> My proposal is to start thinking about miners that join a pool like
>> independent miners and not slave miners, this includes creating a new mi=
ning
>> protocol that does not rely on the pool sending the list of transactions=
to
>> include in a block. Each individual miner has to collect transactions by=
his
>> own and mine that, this can be achieved by running a full node or by run=
ning
>> a SPV like node that ask other nodes for transactions.
>>
>> Once this protocol is developed and standarised we as a community could
>> require all pools to use it (because its better, because is more
>> trustless...), not by imposing it but by recommending it.
>>
>> Pool owners could send some instructions using this protocol to the mine=
r
>> about how many transactions to include per block (some pools want small
>> blocks), how many 0 fee transactions to include, how much is the minimum=
fee
>> per Kb to include transactions and some info about the Coinbase field in=
the
>> block.
>>
>> This way is impossible to perform some of the possible 51% attacks:
>>
>> A pool owner cant mine a new chain (selfish mining) (pool clients have a=
SPV
>> or full node that has checkpoints and ask other peers about the length o=
f
>> the chain)
>> A pool owner can't perform double spends or reverse transactions (pool
>> clients know all the transactions relayed to the network, they know if t=
hey
>> are already included on a block)
>> A pool owner cant decide which transactions not to include (but they can
>> configure the minimum fee).
>> A pool owner cant get all the rewards by avoiding other pools from minin=
g
>> blocks (Because the pool client knows the last block independently that =
is
>> from his pool or other).
>>
>>
>> The only thing that a 51% pool owner can do is to shut down his pool and
>> drop the hashrate by 51% because he does not control the miners.
>>
>> If the pool owner owns all the hardware in the pool my proposal is not
>> valid, if the pool clients dont use this protocol my proposal is not val=
id.
>>
>>
>> I want to know if this is possible or its been developed or there is alr=
eady
>> a working protocol that works like this, also I want to read other peopl=
e's
>> ways to address this threat, thanks for reading.
>>
>> ------------------------------------------------------------------------=
------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solution=
s
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> -------------------------------------------------------------------------=
-----
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|