Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R3rzF-00056L-2b for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 16:06:57 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.41 as permitted sender) client-ip=74.125.82.41; envelope-from=decker.christian@gmail.com; helo=mail-ww0-f41.google.com; Received: from mail-ww0-f41.google.com ([74.125.82.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1R3rzC-0008Ix-Dc for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 16:06:57 +0000 Received: by wwf10 with SMTP id 10so4114891wwf.4 for ; Wed, 14 Sep 2011 09:06:48 -0700 (PDT) Received: by 10.227.156.72 with SMTP id v8mr2414208wbw.110.1316016408256; Wed, 14 Sep 2011 09:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.127.69 with HTTP; Wed, 14 Sep 2011 09:06:08 -0700 (PDT) In-Reply-To: <201109141143.24165.luke@dashjr.org> References: <4E6F83C3.9020108@jerviss.org> <201109141143.24165.luke@dashjr.org> From: Christian Decker Date: Wed, 14 Sep 2011 18:06:08 +0200 Message-ID: To: Bitcoin Development Content-Type: multipart/alternative; boundary=0016e65a0756885f5504ace8f29e X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1R3rzC-0008Ix-Dc Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:06:57 -0000 --0016e65a0756885f5504ace8f29e Content-Type: text/plain; charset=ISO-8859-1 Am I the only one to think putting pools at a disadvantage is actually desirable? Back when pools started to appear we all had huge reservations about putting so much control into the hands of a few pool operators, but nowadays it seems that having pool operators control a vast majority of the computational power is desired. I do like pools (I use them myself), but we should put the security of the protocol in first place and then only think about individual players. Always remember that the problems pool operators encounter are likely also the ones of a potential attacker that tries to accumulate 50%+ of the network power :-) Regards, Chris On Wed, Sep 14, 2011 at 5:43 PM, Luke-Jr wrote: > On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote: > > The block timestamp rules currently give HOURS of wiggle-room for > > timestamps. We can't change those rules without risking a chain split. > > And those hours of wiggle-room are not enough to cause a problem. > The problem only comes in (AFAIK) when the existing rules are *not* > enforced. > > > Assuming a majority of pools/miners adopt the "discourage blocks with > > stale timestamps" rule, that should squash any incentive for cartels > > to try to start playing with difficulty-- you would have to have 50+% > > power to start, or you risk producing mostly orphan blocks. > > As this is against pools/miners' interests, and doesn't seem to solve any > real > problems, I'm going to discourage its adoption if it ever gets done. > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > Learn about the latest advances in developing for the > BlackBerry® mobile platform with sessions, labs & more. > See new tools and technologies. Register for BlackBerry® DevCon today! > http://p.sf.net/sfu/rim-devcon-copy1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --0016e65a0756885f5504ace8f29e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am I the only one to think putting pools at a disadvantage is actually desi= rable?
Back when pools started to appear we all had huge reservations ab= out putting so much control into the hands of a few pool operators, but now= adays it seems that having pool operators control a vast majority of the co= mputational power is desired.
I do like pools (I use them myself), but we should put the security of the = protocol in first place and then only think about individual players.
Al= ways remember that the problems pool operators encounter are likely also th= e ones of a potential attacker that tries to accumulate 50%+ of the network= power :-)

Regards,
Chris
On Wed, Sep 14, 2011 at= 5:43 PM, Luke-Jr <= luke@dashjr.org> wrote:
On Wednesday, September 14, 2011 10:45:36 AM Gavin Andres= en wrote:
> The block timestamp rules currently give HOURS of wiggle-room for
> timestamps. We can't change those rules without risking a chain sp= lit.

And those hours of wiggle-room are not enough to cause a problem.
The problem only comes in (AFAIK) when the existing rules are *not* enforce= d.

> Assuming a majority of pools/miners adopt the "discourage blocks = with
> stale timestamps" rule, that should squash any incentive for cart= els
> to try to start playing with difficulty-- you would have to have 50+%<= br> > power to start, or you risk producing mostly orphan blocks.

As this is against pools/miners' interests, and doesn't seem = to solve any real
problems, I'm going to discourage its adoption if it ever gets done.

---------------------------------------------------------------------------= ---
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry&reg; mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry&reg; DevCon tod= ay!
http://p= .sf.net/sfu/rim-devcon-copy1
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--0016e65a0756885f5504ace8f29e--