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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1WTYQb-0005Lq-J1
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 15:10:41 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WTYQY-0000Vf-26 for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 15:10:41 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Fri, 28 Mar 2014 10:10:30 -0500
id 000000000006A32F.00000000533590E6.0000694C
Date: Fri, 28 Mar 2014 10:10:30 -0500
From: Troy Benjegerdes <hozer@hozed.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@monetize.io>
Message-ID: <20140328151030.GJ3180@nl.grid.coop>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
<20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io>
<20140325122851.GA9818@savin> <5331EF3D.4000504@monetize.io>
<CAAS2fgTovm7OtFFqdRYWDw5KxV+r5WD598JPnG5ydMYAs_gQWg@mail.gmail.com>
<CAC1+kJMkiVLEnHKibWbaCdtEwCE30M4SPM96H6Nq7kZey-_4eg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CAC1+kJMkiVLEnHKibWbaCdtEwCE30M4SPM96H6Nq7kZey-_4eg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WTYQY-0000Vf-26
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
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: Fri, 28 Mar 2014 15:10:41 -0000
> Anyway the particular situation in which a single entity controls 40%
> of the hashing power should be rare. That's potentially dangerous for
> bitcoin and although changing the hashing algorithm would be painful
> and risky, I would be terribly scared of that happening if I was that
> entity. Letting my percentage of hash rate dilute as others grow would
> definitely be part of my plan.
I think *your* plan is an ecologically and socially rational plan. My
observations of irrational responses on this list lead me to believe
there is a single entity (which may be a cartel) which *effectively*
controls between 30% and 50% of the sha-256 hashing power and is quite
terrified of any alternative, and attempts to purchase, consume, or
eliminate any entities that might dilute it's controlled hash rate or
pose a risk of switching to a new algorithm.
We must have a system in which 1 to 10% of the hashrate can provide a
reasonable check-and-balance and competitive pressure to 90% of the
hash rate, or it's going to be fundamentally unstable, and we will
just re-create 'to big to fail' all over again.
> Although this is again completely orthogonal to the merged mining or
> not discussion, hashing algorithms are often mixed in the discussions
> against merged mining. If you had to introduce that hashing algorithm
> hardfork change you will probably chose something with similar
> properties than those of SHA256, like being easy to implement
> specialized hardware for it. You could even chose a memory-hard
> algorithm if you want to promote ASIC production centralization, but
> you can't chose an "anti-ASIC" algorithm because those don't exist.
> It is well known that any information machine that can be built with
> software can also be built with specialized hardware and viceversa.
> Sadly that kind of fallacy is often used to justify the ecological
> crime that starting a new chain with no plans of doing merged mining
> represents.
You speak of ecological crime without proposing any mechanism in which
the ecologically correct thing is also the economically rational thing.
If I could get real-time MISO market pricing for wind energy, I could
do this http://grid.coop/smartgridcmp-long.png and run a mining farm
on my farm.
I would like to propose we collaborate on developing secure mechanism
to audit energy sources for miners on a new chain called 'Ecocoin' in
which the block reward is proportional to how much energy the owner
of the newly generated block reward personally harvested from renewable
sources.
The reward curve will have to be calibrated and adjusted to minimize
the over all costs and fraud risk of auditing the energy input sources.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
|
