From: Karl-Johan Alm <karljohan-alm@garage•co.jp>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Signet
Date: Tue, 12 Mar 2019 14:44:29 +0900 [thread overview]
Message-ID: <CALJw2w7hKRvSL4q0TOWHyc3jKiHYPysfzOLQd06DsS3xy4Ju4g@mail.gmail.com> (raw)
In-Reply-To: <20190310170134.wtml7zuezfadb6hu@email>
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.
next prev parent reply other threads:[~2019-03-12 5:44 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 [this message]
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=CALJw2w7hKRvSL4q0TOWHyc3jKiHYPysfzOLQd06DsS3xy4Ju4g@mail.gmail.com \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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