public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Karl-Johan Alm <karljohan-alm@garage.co.jp>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Date: Sun, 10 Mar 2019 13:01:34 -0400	[thread overview]
Message-ID: <20190310170134.wtml7zuezfadb6hu@email> (raw)
In-Reply-To: <CALJw2w592Gid9cFZ21LKMMVr81_kRpY7rekrvs--dQdGamtaHA@mail.gmail.com>

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

On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> Keeping the PoW rule and moving the signature would mean DoS attacks
> would be trivial as anyone could mine blocks without a signature in
> them

Sure, but anyone could also just connect their lite client to a trusted
node (or nodes) on signet.  The nodes would protect the clients from
missing/invalid-signature DoS and the clients wouldn't have to implement
any more network-level changes than they need to now for testnet.

For people who don't want to run their own trusted signet nodes, there
could be a list of signet nodes run by well-known Bitcoiners (and this
could even be made available via a simple static dns seeder lite clients
could use).

> On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
> > A previous idea regarding reorgs (that I believe Greg came up with)
> > is to allow multiple keys to sign blocks, with one signing no reorgs
> > and one signing a reorg every few blocks, allowing users to choose
> > the behavior they want.
> 
> Not sure how this would work in practice.

This post from Maxwell could be the idea Corallo is describing:

    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html

I read it as:

  - Trusted signer Alice only signs extensions of her previous blocks

  - Trusted signer Bob periodically extends one of Alice's blocks
    (either the tip or an earlier block) with a chain that grows faster
    than Alice's chain, becoming the most-PoW chain.  At some point he
    stops and Alice's chain overtakes Bob's fork as the most-PoW chain

  - User0 who wants to ignore reorg problems starts his node with
    -signet -signers="alice", causing his node to only accept blocks
    from Alice.

  - User1 who wants to consider reorg problems starts his node with
    -signet -signers="alice,bob", causing his node to accept blocks from
    both Alice and Bob, thus experiencing periodic reorgs.

  - There can also be other signing keys for any sort of attack
    that can be practically executed, allowing clients to test their
    response to the attack when they want to but also ignore any
    disruption it would otherwise cause the rest of the time.

  - As an alternative to particular signing keys, there could just be
    flags put in the header versionbits, header nonce, or generation
    transaction indicating how the block should be classified (e.g.
    no_reorg, reorg_max6, reorg_max144, merkle_vulnerability, special0,
    special1, etc...)

(If something like this is implemented, I propose reserving one of the
signing keys/classification flags for use by any of Bitcoin's more
devious devs in unannounced attacks.  Having to occasionally dig
through weird log messages and odd blocks with other Bitcoin dorks on
IRC in order to figure out why things went horribly sideways in our
signet clients sounds to me like an enjoyable experience.  :-)

-Dave

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-03-10 17:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08  5:54 [bitcoin-dev] Signet 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 [this message]
2019-03-12  5:44       ` Karl-Johan Alm
2019-03-13  3:23   ` Anthony Towns
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=20190310170134.wtml7zuezfadb6hu@email \
    --to=dave@dtrt.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=karljohan-alm@garage.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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