From: Troy Benjegerdes <hozer@hozed•org>
To: "Jorge Timón" <jtimon@monetize•io>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Tree-chains preliminary summary
Date: Fri, 28 Mar 2014 10:10:30 -0500 [thread overview]
Message-ID: <20140328151030.GJ3180@nl.grid.coop> (raw)
In-Reply-To: <CAC1+kJMkiVLEnHKibWbaCdtEwCE30M4SPM96H6Nq7kZey-_4eg@mail.gmail.com>
> 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
next prev parent reply other threads:[~2014-03-28 15:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-22 8:47 [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34 ` Peter Todd
2014-03-22 20:12 ` Jorge Timón
2014-03-23 23:17 ` Troy Benjegerdes
2014-03-23 23:53 ` Mark Friedenbach
2014-03-24 20:34 ` Troy Benjegerdes
2014-03-24 20:57 ` Mark Friedenbach
2014-03-25 22:10 ` Troy Benjegerdes
2014-03-26 1:09 ` kjj
2014-03-22 15:08 ` Troy Benjegerdes
2014-03-22 17:04 ` Mark Friedenbach
2014-03-22 19:08 ` Peter Todd
2014-03-23 22:37 ` Troy Benjegerdes
[not found] ` <532DE7E6.4050304@monetize.io>
2014-03-25 12:28 ` [Bitcoin-development] Tree-chains preliminary summary Peter Todd
2014-03-25 12:45 ` Gavin Andresen
2014-03-25 13:49 ` Peter Todd
2014-03-25 15:20 ` Mike Hearn
2014-03-25 16:47 ` Peter Todd
2014-03-25 17:37 ` Jeff Garzik
2014-03-25 18:02 ` Alan Reiner
2014-03-25 18:13 ` slush
2014-03-25 19:47 ` Peter Todd
2014-03-25 21:41 ` Troy Benjegerdes
2014-03-25 20:40 ` Ricardo Filipe
2014-03-25 22:00 ` Troy Benjegerdes
2014-03-26 10:58 ` Peter Todd
2014-03-25 12:50 ` Peter Todd
2014-03-25 21:03 ` Mark Friedenbach
2014-03-25 22:34 ` Gregory Maxwell
2014-03-27 16:14 ` Jorge Timón
2014-03-28 15:10 ` Troy Benjegerdes [this message]
2014-04-17 21:41 ` Tier Nolan
2014-03-26 10:48 ` Peter Todd
2014-08-03 17:23 ` Gregory Sanders
2014-03-24 21:17 ` [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140328151030.GJ3180@nl.grid.coop \
--to=hozer@hozed$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jtimon@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox