public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: Ruben Somsen <rsomsen@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Nathan T Alexander <nta@nathanalexander•net>
Subject: Re: [bitcoin-dev] Question- must every mining rig attempt every block?
Date: Fri, 8 Oct 2021 11:08:02 -0400	[thread overview]
Message-ID: <CAGpPWDax_Ht0H-Ct_SfaFF7AD-nUH-T1Sfo9+c7M6ptUK8ifzw@mail.gmail.com> (raw)
In-Reply-To: <CAPv7TjZA2KYeVnT6PE6UHXwPy__E-VOvjmYD1207f1CgBRhLZg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3334 bytes --]

Proof of stake systems attempt to create red light - green light types of
things with non-gameable attributes (eg collaborative random numbers). This
can't be done with mining because mining is completely random - its not
possible to know which miner will mine a block. If it were, it wouldn't be
proof of work, but something else. What you describe sounds like proof of
identity, which isn't possible in a decentralized adversarial environment.
In fact, one of the primary achievements of the Proof of Work consensus
mechanism is to work around the Sybil issue, where (like ZmnSCPxj
mentioned) a single user can have many identities.

There can be hybrid systems that use both proof of work and proof of stake,
but my conclusion after having done a lot of research and thinking about it
([1]
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity>,
[2] <https://github.com/fresheneesz/proofOfTimeOwnership>) is that the
security mostly boils down to the weakest piece of the hybrid system, and
so its not very effective to have hybrid systems like you mentioned.

On Tue, Oct 5, 2021 at 10:43 AM Ruben Somsen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi Nathan,
>
> That's a fair question, but note that we've already had a bunch of "green
> mining" related posts a few months ago, so I suspect you'll be able to find
> many criticisms to this idea in the following thread:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018937.html
>
> It also looks like you'll be able to find some related answers on Bitcoin
> Stack Exchange:
>
> https://bitcoin.stackexchange.com/questions/106308/decreasing-energy-consumption-of-bitcoins-pow-with-paired-mining-rounds
>
> And generally speaking these types of discussions don't end up being very
> fruitful for bitcoin-dev, because these are the types of changes that are
> unlikely to ever be seriously considered for Bitcoin.
>
> Cheers,
> Ruben
>
> On Tue, Oct 5, 2021 at 4:09 PM Nathan T Alexander via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> For purposes of conserving energy, couldn't each mining rig have some
>> non-gameable attribute which would be used to calculate if a block would
>> be accepted by that rig?
>>
>> Don't the mining rigs have to be able to identify themselves to the
>> network somehow, in order to claim their block reward? Could their
>> bitcoin network ID be used as a non-gameable attribute?
>>
>> Essentially a green light / red light system. In order for a block to be
>> accepted by the network, it must have all attributes of a successful
>> block today, and it must also have come from a rig that had a green light.
>>
>> Perhaps hash some data from the last successful block, along with the
>> miners non-gameable attribute, and if it's below a certain number set by
>> algorithm, the miner gets a green light to race to produce a valid block.
>>
>> Nathan Alexander
>>
>> Arlington, TX
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4849 bytes --]

      reply	other threads:[~2021-10-08 15:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 12:23 Nathan T Alexander
2021-10-05 14:41 ` ZmnSCPxj
2021-10-05 14:42 ` Ruben Somsen
2021-10-08 15:08   ` Billy Tetrud [this message]

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=CAGpPWDax_Ht0H-Ct_SfaFF7AD-nUH-T1Sfo9+c7M6ptUK8ifzw@mail.gmail.com \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=nta@nathanalexander$(echo .)net \
    --cc=rsomsen@gmail$(echo .)com \
    /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