From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Date: Mon, 4 Nov 2013 07:51:07 -0800 [thread overview]
Message-ID: <CAAS2fgQsq0XWb7FZRFrJUmorQfeS=xXa-R4LWneq2LS48tFmng@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn <mike@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.
next prev parent reply other threads:[~2013-11-04 15:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 11:26 Mike Hearn
2013-11-04 11:53 ` Peter Todd
2013-11-04 12:00 ` Mike Hearn
2013-11-04 18:16 ` [Bitcoin-development] Committing to extra block data/a better merge-mine standard Peter Todd
2013-11-04 18:32 ` Peter Todd
2013-11-04 19:11 ` Mark Friedenbach
2013-11-15 22:06 ` Peter Todd
2013-11-04 19:38 ` Mike Hearn
2013-11-04 19:53 ` Mark Friedenbach
2013-11-04 20:10 ` Mike Hearn
2013-11-04 11:58 ` [Bitcoin-development] Auto-generated miner backbone Michael Gronager
2013-11-04 12:03 ` Mike Hearn
2013-11-04 12:20 ` Peter Todd
2013-11-04 12:40 ` Michael Gronager
2013-11-04 15:58 ` Gregory Maxwell
2013-11-04 14:26 ` Peter Todd
2013-11-04 14:34 ` Pieter Wuille
2013-11-04 14:46 ` Peter Todd
[not found] ` <CABT1wWm1NzKSS9H=Qh3Z6pFmNHbOFKC12WaE=b3kE0mNsRgfmw@mail.gmail.com>
2013-11-04 15:04 ` Peter Todd
[not found] ` <CABT1wWmONUeOWRg-=FKr88bgBQf0un4bvjYW2h8d-10ys-VKtA@mail.gmail.com>
2013-11-04 15:46 ` Peter Todd
[not found] ` <CABT1wWmM466jWWdWAo5GmzP58xJFT70Vcr74ta+2QF2fWT+1SA@mail.gmail.com>
2013-11-04 16:07 ` Peter Todd
[not found] ` <CABT1wWm5BDZf7U40pOqZvTqdOKeTWUTekjUNckq5McMV=LDu_g@mail.gmail.com>
2013-11-04 16:51 ` Peter Todd
[not found] ` <CABT1wWmwb17b4ACHMmDKqd94tUSKsvwAPx344mZ0VS+47myeWg@mail.gmail.com>
2013-11-04 21:04 ` Peter Todd
2013-11-04 21:45 ` Alan Reiner
2013-11-04 22:03 ` Peter Todd
2013-11-04 15:27 ` Mike Hearn
2013-11-04 17:36 ` Peter Todd
2013-11-04 15:51 ` Gregory Maxwell [this message]
2013-11-05 4:14 Gustaw Wieczorek
2013-11-05 4:39 ` Peter Todd
2013-11-05 6:37 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQsq0XWb7FZRFrJUmorQfeS=xXa-R4LWneq2LS48tFmng@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox