đź“… Original date posted:2013-11-04
đź“ť Original message:On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn <mike at plan99.net> wrote:
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change. 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?
Yea, I've proposed this too (both in the past and in the context of
this). I don't think, however, that the announcements need to be the
miners themselves— but instead just need to be nodes that the miners
think are good (and, for their own sake— ones they're well connected
to).
Miner's could keep a list of address messages nodes they
like/are-connected to, perhaps prioritizing their own nodes, than
exclude ones which are already in the most recent blocks, and include
the best remaining. Of course, if it's using address messages (or
perhaps a new address message syntax) it would automatically support
hidden services.
They should probably be included as OP_RETURN outputs in coinbase
transactions, maybe only limited (by what other clients pay attention
to) to one or two per block.
This should make it harder to get partitioned from the majority
hashrate (or partition the majority hashrate from itself), though
these hosts would be DOS targets, so it isn't a silver bullet.
Making the majority hashrate self-unpartitionabilty stronger is
possible— have miners add an encryption key to their coinbase
transactions, then have subsequent miners mine encrypted addr messages
to single other block sources to automatically weave a miner darknet
with access controlled by successful block creation. But I doubt it's
worth the complexity of bandwidth.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:08:40
in reply to nevent1q…vdwd
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:08:40Event JSON
{
"id": "589a7548d18a9bcc8d019dc66115c53d7f537c2ff6b7882911fe6e55a2612fe7",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150520,
"kind": 1,
"tags": [
[
"e",
"765fed6c29fdbe34a8d684f2c378c7af27425335b84117da7738480c60386dd8",
"",
"root"
],
[
"e",
"1a7da88a6bb7abe612f39b7b7321fee3f04639264d782c966177cc3e54e195fe",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-11-04\n📝 Original message:On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e I'm wondering about an alternative protocol change that perhaps has less\n\u003e subtle implications than their suggested change. 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\nYea, I've proposed this too (both in the past and in the context of\nthis). I don't think, however, that the announcements need to be the\nminers themselves— but instead just need to be nodes that the miners\nthink are good (and, for their own sake— ones they're well connected\nto).\n\nMiner's could keep a list of address messages nodes they\nlike/are-connected to, perhaps prioritizing their own nodes, than\nexclude ones which are already in the most recent blocks, and include\nthe best remaining. Of course, if it's using address messages (or\nperhaps a new address message syntax) it would automatically support\nhidden services.\n\nThey should probably be included as OP_RETURN outputs in coinbase\ntransactions, maybe only limited (by what other clients pay attention\nto) to one or two per block.\n\nThis should make it harder to get partitioned from the majority\nhashrate (or partition the majority hashrate from itself), though\nthese hosts would be DOS targets, so it isn't a silver bullet.\n\nMaking the majority hashrate self-unpartitionabilty stronger is\npossible— have miners add an encryption key to their coinbase\ntransactions, then have subsequent miners mine encrypted addr messages\nto single other block sources to automatically weave a miner darknet\nwith access controlled by successful block creation. But I doubt it's\nworth the complexity of bandwidth.",
"sig": "5d384f0226de1dac184452a13a175d9d2187eed237de5a16c75caae1fde8264b80d2a828c25183827d211d472ac44773354cca5f930d5b635fc5ff0065c005c4"
}