From: Billy Tetrud <billy.tetrud@gmail•com>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
Date: Tue, 18 Jan 2022 12:15:15 -0600 [thread overview]
Message-ID: <CAGpPWDaTb0+jbWzC46K9jnS6-DRb5opDXnmA83P5SeTzACBuaA@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhhNgVp1wb3+CEAnGmCoYHFKQPPqRg-WvkCuaD+8WAAG_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
@vjudeu
> If you introduce signing into mining, then you will have cases, where
someone is powerful enough to produce blocks, but cannot, because signing
is needed.. your consensus is no longer "the heaviest chain"
You've misunderstood my suggestion. This would not be possible with what I
suggested. Why do you think of the signature as some kind of barrier? What
I was suggesting was that, when a miner participating in this protocol
mines a valid bitcoin block, they then sign a superblock with a public key
that can be verified alongside the coinbase output (eg say with data in the
first tapleaf of the output address). The block is still connected to
something secured by PoW. You really made a lot of incorrect assumptions
about what I suggested.
On Thu, Dec 23, 2021 at 1:05 PM Jeremy <jlrubin@mit•edu> wrote:
> If you introduce signing into mining, then you will have cases, where
>> someone is powerful enough to produce blocks, but cannot, because signing
>> is needed. Then, your consensus is no longer "the heaviest chain", but "the
>> heaviest signed chain". That means, your computing power is no longer
>> enough by itself (as today), because to make a block, you also need some
>> kind of "permission to mine", because first you sign things (like in
>> signet) and then you mine them. That kind of being "reliably unreliable"
>> may be ok for testing, but not for the main network.
>
>
> this is a really great point worth underscoring. this is the 'key
> ingredient' for DCFMP, which is that there is no signing or other network
> system that is 'in the way' of normal bitcoin mining, just an opt-in set of
> rules for sharing the bounties of your block in exchange for future shares.
>
[-- Attachment #2: Type: text/html, Size: 2559 bytes --]
next prev parent reply other threads:[~2022-01-18 18:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-12 16:43 Jeremy
2021-12-12 23:14 ` vjudeu
2021-12-13 1:31 ` Jeremy
[not found] ` <20211214190524.GA30559@mcelrath.org>
2021-12-14 19:39 ` Jeremy
2021-12-14 19:50 ` Jeremy
2021-12-15 0:12 ` Bob McElrath
2021-12-15 17:25 ` Billy Tetrud
2021-12-15 18:39 ` Jeremy
2021-12-15 18:51 ` Bob McElrath
2021-12-16 9:35 ` vjudeu
2021-12-16 16:57 ` Billy Tetrud
2021-12-17 0:37 ` Jeremy
2021-12-17 6:37 ` vjudeu
2021-12-20 17:18 ` Billy Tetrud
2021-12-23 11:56 ` vjudeu
2021-12-23 19:05 ` Jeremy
2022-01-18 18:15 ` Billy Tetrud [this message]
2021-12-14 23:33 ` Bob McElrath
2021-12-15 21:10 ` yanmaani
2021-12-15 21:53 ` Jeremy
2021-12-13 14:10 vjudeu
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=CAGpPWDaTb0+jbWzC46K9jnS6-DRb5opDXnmA83P5SeTzACBuaA@mail.gmail.com \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/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