From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Date: Wed, 13 Mar 2019 13:23:46 +1000 [thread overview]
Message-ID: <20190313032346.ep472iuhayfzk5e5@erisian.com.au> (raw)
In-Reply-To: <939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.
Maybe make the signature be an optional addition to the header, so
that you can have a "light node" that doesn't download/verify sigs
and a full node that does? (So signatures just sign the traditional
80-byte header, and aren't included in the block's tx merkle root, and
the prevHash reflects the hash of the previous block's 80-byte header,
without the signature)
I think you could do that by adding a p2p service bit to say "send me
signatures if you have them / I can send you signatures", which changes
the p2p encoding of the header from (ver, prev, mrkl, time, bits, nonce)
to (ver, prev, mrkl, time, 0, nonce, bits, sig), and change header
processing to ignore headers from nodes that don't have the service
bit set?
If you did this, it might be a good idea to enforce including the previous
block's header signature in the current block's coinbase.
Cheers,
aj
next prev parent reply other threads:[~2019-03-13 3:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 5:54 Karl-Johan Alm
2019-03-08 20:20 ` Matt Corallo
2019-03-10 0:43 ` Karl-Johan Alm
2019-03-10 17:01 ` David A. Harding
2019-03-12 5:44 ` Karl-Johan Alm
2019-03-13 3:23 ` Anthony Towns [this message]
2019-03-14 1:07 ` Karl-Johan Alm
2019-03-09 19:52 ` Lautaro Dragan
2019-03-10 1:02 ` Karl-Johan Alm
2019-03-13 9:15 Varunram Ganesh
[not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
2019-03-14 1:17 ` Karl-Johan Alm
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=20190313032346.ep472iuhayfzk5e5@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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