From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59519C002D for ; Tue, 12 Jul 2022 00:21:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 345A084077 for ; Tue, 12 Jul 2022 00:21:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 345A084077 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=mk5NY3I+ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Haf_ybmPM0VV for ; Tue, 12 Jul 2022 00:21:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 73C6884072 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by smtp1.osuosl.org (Postfix) with ESMTPS id 73C6884072 for ; Tue, 12 Jul 2022 00:21:52 +0000 (UTC) Received: by mail-qv1-xf36.google.com with SMTP id d17so1547191qvs.0 for ; Mon, 11 Jul 2022 17:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wIpHg8y0BJK1vsbvPOrRpt3SpaZBMS06qXaMNR3WsbE=; b=mk5NY3I+ZOeW3sArIzjBdchTxKTJVQ1bxNAEO+q/cgzqMKPJVyelxEIrkPouqIlvRi 25dBnt0NRU0FYhEsnJldbHrxrZySu/pf7FZsXJ2kBrI7MoSRrDJxlha1MNJ9Qqa6TtWV RYuTeAvHyVZ0UKrKUII3DfxedjPVuSVxSf0Jmn36nHMR8DQ+jfp2m1O34ZSAqi6SbNKc U77+79BCWhxxqIw6+6w6fP994ouTKCxL1Uy+xiO3ND2dSlJTqr7QPI6c7Hx/848/bA1K mf66QBrZtQ/UXAmjcTfjPO405b5Mi4Li6/SJbzjIG1jXC+j01Nx2Uj1iQLii7oiQ6L95 zuyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wIpHg8y0BJK1vsbvPOrRpt3SpaZBMS06qXaMNR3WsbE=; b=ME1BfwYDyZGVGvcpuajrK9ejvS3xYP/Wf2GDm7gZnA5OdtZ52RmONzvCK1kQ+NqF1V z/dJmtM9YDsq4T/4MSlPfmLEERodtFE1OUgHzfbW2Ip0RyvVNdgSIYTZjTU53a2w9ltd z9MTtptfwC3mW1dvZ3GPiaPXIhV5nCXdI32pN0aizAMR9Ap4ItmxfgP7+kgCtfDGUguZ YtOLzsHJPBoClvHIZt/0sRIa343XFE8Lyp3fjONg77PwzRJWMav51b8IsUfggnmjXVKy d12aZgIo9Uj/CnSl776B7vKagd5h+diRf513WFPcP9rO1Cc3nvFUC45VLTdAg1jvMu0O Pvag== X-Gm-Message-State: AJIora9f9TgiOzsDIx1lj3UTQFa5d1cTWRLWwLoGDP5u61WK8CdqE91+ vZbIWIp3PbY3HBRcSfHzckR8ji5EfbpN+cibMkMBQH7o1fRMQw== X-Google-Smtp-Source: AGRyM1tmRo+2c7x0jfxkS9pCWHQ1AwVAN3wxw9yk1zF6HB62gdXY36S1w9393yzHTiQTVZ+6isdBlW+D6D56sn/KWzg= X-Received: by 2002:a0c:9c48:0:b0:473:5e9e:741 with SMTP id w8-20020a0c9c48000000b004735e9e0741mr9289663qve.63.1657585311087; Mon, 11 Jul 2022 17:21:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Mon, 11 Jul 2022 20:21:40 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a7181f05e390a76a" Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 00:21:56 -0000 --000000000000a7181f05e390a76a Content-Type: text/plain; charset="UTF-8" Oops, you are right. We need the bribe to be the output of the coinbase, but due to the maturity rule, it isn't really a bribe. Too bad coinbases cannot take other coinbase outputs as inputs to bypass the maturity rule. I guess that means the bribe has to be by leaving transactions in the mempool. Also your point about centralization pressure is well taken. On Mon, Jul 11, 2022 at 5:56 PM Peter Todd wrote: > On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote: > > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via > bitcoin-dev wrote: > > > > What happens after that I'm not sure. > > > > > > > > > > Miners will learn to create anyone-can-spend outputs to bribe other > miners > > > to build on their block rather than reorg it. (Due to the coinbase > > > maturity, this will require some amount of floating capital.) > > > > ...and that's a disaster for mining centralization, because the smaller > miners > > need to pay larger bribes than larger miners. Not to mention having to > keep > > capital around to do it. > > Also, note how from a practical point of view, we'll need to add a new > type of > tx that's only valid in a specific block, or other miners will just reorg > those > anyone-can-spend outputs to steal them. It's not all that trivial to > actually > do that... you'd have to have a signature that commits to the non-segwit > part > of the coinbase outputs. Ugh. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --000000000000a7181f05e390a76a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops, you are right.=C2=A0 We need the bribe to be th= e output of the coinbase, but due to the maturity rule, it isn't really= a bribe.

Too bad coinbases cannot take other= coinbase outputs as inputs to bypass the maturity rule.

I guess that means the bribe has to be by leaving transactions= in the mempool.

Also your point about centralizat= ion pressure is well taken.

=
On Mon, Jul 11, 2022 at 5:56 PM Peter= Todd <pete@petertodd.org> = wrote:
On Mon, J= ul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bit= coin-dev wrote:
> > > What happens after that I'm not sure.
> > >
> >
> > Miners will learn to create anyone-can-spend outputs to bribe oth= er miners
> > to build on their block rather than reorg it.=C2=A0 (Due to the c= oinbase
> > maturity, this will require some amount of floating capital.)
>
> ...and that's a disaster for mining centralization, because the sm= aller miners
> need to pay larger bribes than larger miners. Not to mention having to= keep
> capital around to do it.

Also, note how from a practical point of view, we'll need to add a new = type of
tx that's only valid in a specific block, or other miners will just reo= rg those
anyone-can-spend outputs to steal them. It's not all that trivial to ac= tually
do that... you'd have to have a signature that commits to the non-segwi= t part
of the coinbase outputs. Ugh.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--000000000000a7181f05e390a76a--