These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of
a road map related to a goal of increase scaling. One of the metrics
would be a decentralization metric. (A framework for a decentralization
metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.
Russ
On 7/30/2015 7:33 PM, Eric Lombrozo via bitcoin-dev wrote:
On Jul 30, 2015, at 5:29 AM, Gavin <gavinandre...@gmail.com
<mailto:gavinandre...@gmail.com>> wrote:
it is hard to have a rational conversation about that when even simple
questions like 'what is s reasonable cost to run a full node' are met
with silence.
Some of the risks are pretty hard to quantify. But I think this misses
the bigger point - it very well *might* be possible to safely raise this
limit or even get rid of it by first fixing some serious issues with the
protocol. But over six years into the project and these issues continue
to be all-but-ignored by most of the community (including at least a few
core developers). I don’t think it’s really a matter of whether we agree
on whether it’s good to raise the block size limit, Gavin. I think it’s
a matter of a difference in priorities.
- Eric
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
