📅 Original date posted:2013-11-04
📝 Original message:On 4/11/13, 12:26 , Mike Hearn wrote:
> W.R.T. this paper and the oft-discussed miner backbone,
>
> http://arxiv.org/pdf/1311.0243v1.pdf
>
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change.
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem. It is actually a
mental shortcut in the assumption of how probability works when mining a
chain. The paper simply corrects this error - nice work!
> Rather than address the
> problem by assuming the network is full of sybil nodes and changing the
> rules for selecting the chain to build on, how about if we wrote code to
> automatically build a miner backbone by having IP addresses of nodes
> embedded into coinbases, then having any bitcoind that is creating work
> automatically connect to IPs that appeared in enough recent blocks?
You suggestion could perhaps be fun for other purposes, but does not
rule out pools of "selfish miners". Further, it binds physical state
(ip) to the blockchain, which has so far held no assumptions on the
technology of the system on which it is running.
>
> This would have the effect of automatically linking all the major pools
> together, with no administration overhead.
>
> For bonus points, the IPs could be IPv6 and then the trick we use to
> pack hidden services into IPv6 address space would allow nodes to be
> reached via Tor. This might be useful in the case of pools that don't to
> reveal the location of their bitcoin node[s], like for anti-DoS reasons.
>
> It feels like this should be achievable with a few days of solid coding
> and a couple of new command line flags, and the impact is much easier to
> reason about than a fundamental rule change like the one proposed by the
> paper.
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Michael Gronager [ARCHIVE] /
npub1nc…gw452
2023-06-07 15:08:37
in reply to nevent1q…5d2m
Author Public Key
npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452Published at
2023-06-07 15:08:37Event JSON
{
"id": "f4bc40e409f6e5fd437a9a728dcfef3d4a2428bf6fbad40f3038de046214556b",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686150517,
"kind": 1,
"tags": [
[
"e",
"765fed6c29fdbe34a8d684f2c378c7af27425335b84117da7738480c60386dd8",
"",
"root"
],
[
"e",
"6441ff06603ea80cd2b5e740969bb4b2b3c3b25d95a51d2dec41e5caf792eb89",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-11-04\n📝 Original message:On 4/11/13, 12:26 , Mike Hearn wrote:\n\u003e W.R.T. this paper and the oft-discussed miner backbone,\n\u003e \n\u003e http://arxiv.org/pdf/1311.0243v1.pdf\n\u003e \n\u003e I'm wondering about an alternative protocol change that perhaps has less\n\u003e subtle implications than their suggested change. \n\nThe suggested change is actually very simple (minutes of coding) and\nelegant and addresses precisely the identified problem. It is actually a\nmental shortcut in the assumption of how probability works when mining a\nchain. The paper simply corrects this error - nice work!\n\n\u003e Rather than address the\n\u003e problem by assuming the network is full of sybil nodes and changing the\n\u003e rules for selecting the chain to build on, how about if we wrote code to\n\u003e automatically build a miner backbone by having IP addresses of nodes\n\u003e embedded into coinbases, then having any bitcoind that is creating work\n\u003e automatically connect to IPs that appeared in enough recent blocks? \n\nYou suggestion could perhaps be fun for other purposes, but does not\nrule out pools of \"selfish miners\". Further, it binds physical state\n(ip) to the blockchain, which has so far held no assumptions on the\ntechnology of the system on which it is running.\n\n\u003e \n\u003e This would have the effect of automatically linking all the major pools\n\u003e together, with no administration overhead.\n\u003e \n\u003e For bonus points, the IPs could be IPv6 and then the trick we use to\n\u003e pack hidden services into IPv6 address space would allow nodes to be\n\u003e reached via Tor. This might be useful in the case of pools that don't to\n\u003e reveal the location of their bitcoin node[s], like for anti-DoS reasons.\n\u003e \n\u003e It feels like this should be achievable with a few days of solid coding\n\u003e and a couple of new command line flags, and the impact is much easier to\n\u003e reason about than a fundamental rule change like the one proposed by the\n\u003e paper.\n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Android is increasing in popularity, but the open development platform that\n\u003e developers love is also attractive to malware creators. Download this white\n\u003e paper to learn more about secure code signing practices that can help keep\n\u003e Android apps secure.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=65839951\u0026iu=/4140/ostg.clktrk\n\u003e \n\u003e \n\u003e \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",
"sig": "fe3e9b8dec0f0d22f47ff7426764a197d1c2c1daba5d6907f0113d714c01e2fcbd25e83f32b7052572fb0a9c6ba0ce61a7ded9fe380b4784470e763b674105e3"
}