It cannot possibly be enforced.  Enforcement is not important when you're setting defaults.  In fact, you don't want to enforce defaults, but rather allow anyone who cares to deviate from them to do so.

The importance of default behavior is proportional to the number of folks who mess with the defaults, and that, among miners, is pretty small as far as I know, at least in the area of deciding how to decide which block to build on when two show up at nearly the same time.

On Tue, Dec 29, 2015 at 11:25 AM, Allen Piscitello <allen.piscitello@gmail.com> wrote:
How could this possibly be enforced?

On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
There have been no decent objections to altering the block-selection mechanism (when two block solutions appear at nearly the same time) as described at

http://bitcoin.stackexchange.com/questions/39226

Key components are:
  • Compute BitcoinDaysDestroyed using only transactions that have been in your mempool for some time as oBTCDD ("old BTCDD").
  • Use "nearly the same time" to mean separated in time by your guess of the average duration of block propagation times.
  • When two block solutions come in at nearly the same time, build on the one that has the most oBTCDD, rather than the one that came in first.

The goal of this change is to reduce the profitability of withholding block solutions by severely reducing the chances that a block solved a while ago can orphan one solved recently.  "Came in first" seems more easily gamed than "most oBTCDD".  As I wrote there, "old coins is always a dwindling resource and global nodes willing to help cheat is probably a growing one."

I will write a BIP if anyone agrees it's a good idea.


On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Far more concerning is network propagation effects between large and
small miners. For that class of issues, if you are in an environemnt
where selfish mining is possible - a fairly flat, easily DoS/sybil
attacked network topology - the profitability difference between small
and large miners even *without* attacks going on is a hugely worrying
problem. OTOH, if you're blocksize is small enough that propagation time
is negligable to profitability, then selfish mining attacks with <30%
hashing power aren't much of a concern - they'll be naturally defeated
by anti-DoS/anti-sybil measures.

Let's agree that one factor in mining profitability is bandwidth/network reliability/stability. Why focus on that vs electricity contracts or vertically integrated chip manufacturers? Surely, sufficient network bandwidth is a more broadly available commodity than <$0.02/kwh electricity, for example. I'm not sure that your stranded hydroelectric miner is any more desirable than thousands of dorm room miners with access to 10gbit university connections and free electricity.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




--
I like to provide some work at no charge to prove my value. Do you need a techie? 
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev





--
I like to provide some work at no charge to prove my value. Do you need a techie? 
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto