MIME-Version: 1.0
References: <CALJw2w5OiKHk1oj1p=rmQ-jvYOdieOD=xHcPt9D0A_-nLKvv7Q@mail.gmail.com>
	<939C132D-8599-4258-8F14-62E992BA9F51@mattcorallo.com>
	<CALJw2w592Gid9cFZ21LKMMVr81_kRpY7rekrvs--dQdGamtaHA@mail.gmail.com>
	<20190310170134.wtml7zuezfadb6hu@email>
In-Reply-To: <20190310170134.wtml7zuezfadb6hu@email>
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Tue, 12 Mar 2019 14:44:29 +0900
Message-ID: <CALJw2w7hKRvSL4q0TOWHyc3jKiHYPysfzOLQd06DsS3xy4Ju4g@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Precedence: list

Hello all,

I started writing code that puts the signature in the coinbase
transaction similar to the witness commitment, and encountered a
potential issue. See inline comments below.

On Mon, Mar 11, 2019 at 2:02 AM David A. Harding <dave@dtrt.org> wrote:
>
> 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).

This sounds sensible. One issue here is that the "proper" signer will
be orders of magnitude slower than the fake miner when constructing
blocks. Because the signature is now stuffed into the coinbase
transaction, it becomes a part of the block merkle root, so the true
miner now has to (1) create a block, (2) sign it, (3) check if hash <
target, (4) nudge nonce if not, and then repeat from step (2) until it
finds a valid block. I.e. it has to sign the entire thing for every
nonce.

> This post from Maxwell could be the idea Corallo is describing:
>
>     https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html

That's pretty cool. The plan I had was to set up some simple interface
where anyone could "order" reorgs whenever they wanted to. It would
reorg/double spend people on request (e.g. "send 1 signetcoin to
signet1qfoobar and then double spend it in a reorg 3 blocks deep") and
so on.

With that kind of tool, I don't know if you need the alternate signing
approach you described, but I could be mistaken.