📅 Original date posted:2011-09-14
🗒️ Summary of this message: The security of the Bitcoin protocol should be the top priority, even if it means putting pools at a disadvantage. Pool operators' problems are also potential attackers' problems.
📝 Original message: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 <luke at dashjr.org> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110914/7cbfb95f/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 02:25:33
in reply to nevent1q…r28l
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 02:25:33Event JSON
{
"id": "b04464fe4b69a067809f1433b08218e4fc43852cf634d9a2fad5ac6a514407ba",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686104733,
"kind": 1,
"tags": [
[
"e",
"c5d8eb0720120c08594c588b2c728c7a4f1ca34d1ae4dfac6ef6225ba2d5a835",
"",
"root"
],
[
"e",
"66b2df5554d08969bb49d0bf1256bb2f9d8ff61608908ee70a5d4bd64cdaf9e0",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2011-09-14\n🗒️ Summary of this message: The security of the Bitcoin protocol should be the top priority, even if it means putting pools at a disadvantage. Pool operators' problems are also potential attackers' problems.\n📝 Original message:Am I the only one to think putting pools at a disadvantage is actually\ndesirable?\nBack when pools started to appear we all had huge reservations about putting\nso much control into the hands of a few pool operators, but nowadays it\nseems that having pool operators control a vast majority of the\ncomputational power is desired.\nI do like pools (I use them myself), but we should put the security of the\nprotocol in first place and then only think about individual players.\nAlways remember that the problems pool operators encounter are likely also\nthe ones of a potential attacker that tries to accumulate 50%+ of the\nnetwork power :-)\n\nRegards,\nChris\nOn Wed, Sep 14, 2011 at 5:43 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:\n\u003e \u003e The block timestamp rules currently give HOURS of wiggle-room for\n\u003e \u003e timestamps. We can't change those rules without risking a chain split.\n\u003e\n\u003e And those hours of wiggle-room are not enough to cause a problem.\n\u003e The problem only comes in (AFAIK) when the existing rules are *not*\n\u003e enforced.\n\u003e\n\u003e \u003e Assuming a majority of pools/miners adopt the \"discourage blocks with\n\u003e \u003e stale timestamps\" rule, that should squash any incentive for cartels\n\u003e \u003e to try to start playing with difficulty-- you would have to have 50+%\n\u003e \u003e power to start, or you risk producing mostly orphan blocks.\n\u003e\n\u003e As this is against pools/miners' interests, and doesn't seem to solve any\n\u003e real\n\u003e problems, I'm going to discourage its adoption if it ever gets done.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e BlackBerry\u0026reg; DevCon Americas, Oct. 18-20, San Francisco, CA\n\u003e Learn about the latest advances in developing for the\n\u003e BlackBerry\u0026reg; mobile platform with sessions, labs \u0026 more.\n\u003e See new tools and technologies. Register for BlackBerry\u0026reg; DevCon today!\n\u003e http://p.sf.net/sfu/rim-devcon-copy1\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110914/7cbfb95f/attachment.html\u003e",
"sig": "24016ac10d415ed8aa8a60afe877c58cad395db46f3c8249a0826d53a6f339eb2d748727255f66bd7c172e4b81333bea875dcba9f45d52607a343534a607d504"
}