path: root/c2/53a68c5245c7f4bb61317b6befb940c154d404

Return-Path: <joost.jager@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5EAEBC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 12:31:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 39C62820ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 12:31:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 39C62820ED
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=c3jSkLZ+
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 scYYRDAXjVF1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 12:31:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0311A8209C
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [IPv6:2a00:1450:4864:20::62f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 0311A8209C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 12:31:29 +0000 (UTC)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-96f683e8855so633063566b.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 05:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685449888; x=1688041888;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=dauS6D5nhATDMXN759Z8ymzkm7jTj4xKZDJxjVctsNo=;
 b=c3jSkLZ+hWZ8dxFgAwW/rpYolY9XScBGWhGq45Fj3sqP9jchZabdM/N4XM8CyHl5Hr
 lS0QGDQoDnF9ttXRKDTJwOtuRnwksx5evbJ30JbIjrrC4x1ew4ik47fq/s1xx1MKLRnv
 oWSttOQP8lXO3Od7uwLRhOQGymaAcsCWi0JSbjVTK+i2RsC+nhQeJi2S2/Ayiw2q1R+M
 V8xru0Qcs10BjPkPEHSQZwa45oL6Gnj/Hxlkc5ENVMn04EiYhZcNhtn4kFAx3EmH/bNn
 6H8yzfd7pTIW3S1s3Fxx8fvAr9/1EZXE+H0EQfqn890R1CwdQpFIzWFXtd/1BMJpyGX7
 OfOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685449888; x=1688041888;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=dauS6D5nhATDMXN759Z8ymzkm7jTj4xKZDJxjVctsNo=;
 b=DflnjPX10YRr8LLDBig39C0oeZ1Mz2gvrfzpktO7amWdYb7QxxvomDkkuI0f2vpS04
 GI79HfFmpDZJH86aPUTIkYHpmnn6uMkGGeDlBGiWrrG0A6lCBUbgbMXPD68xbfnPBICJ
 c5kmq/ZWvWdi2/6swI9bkIi8ohJCOMkFaG6gGG5D2TYJ5n1INgWwAiKlXGBm0xd5016H
 MO6x5EFSixdug0MeGkajfDMWg/9zoFs2Ls3Y3mS6jPvHoBv6A0AqQmICK48+PthE2UFY
 a+YjIiGiFzL9//VEjst+vsdQA/jEv2jwWbImZJv/lG3LOWhFxOJl1ip9ekvMVa8eOmYl
 CjFA==
X-Gm-Message-State: AC+VfDy7UUD1mW1+mTs57SPVtR4ZHXPD2lrYWPptEpESacaVZrvRGPgN
 R6HY1Q7Kl6BoIOCzJp3OyAaiS35YU5cfvkAlT870iFCT
X-Google-Smtp-Source: ACHHUZ4wQz8iMj7odhxRlleCdhrHdEg1okaLRZ1JO/UZXfyPF0jkiSeNUgx0kcmJ7l0Svi1DadPz5m61XbbLPRIUfY0=
X-Received: by 2002:a17:907:a41e:b0:970:10a9:3ca8 with SMTP id
 sg30-20020a170907a41e00b0097010a93ca8mr2510721ejc.22.1685449887764; Tue, 30
 May 2023 05:31:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
 <020c50422fb4bc03fe1d6f06c2ae751f@dtrt.org>
In-Reply-To: <020c50422fb4bc03fe1d6f06c2ae751f@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 30 May 2023 14:30:51 +0200
Message-ID: <CAJBJmV-=berWDEeXfLcfyqQQPL5m32St9XUd02bTXJVOHZsM+Q@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000d8d3f405fce861fc"
X-Mailman-Approved-At: Tue, 30 May 2023 12:58:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2023 12:31:32 -0000

--000000000000d8d3f405fce861fc
Content-Type: text/plain; charset="UTF-8"

Hi David,


> A block template is an ordered list of raw transactions that can all be
> included in the next block (with some space reserved for a coinbase
> transaction).  A full node can validate those transactions and calculate
> how much fee they pay.  A Nostr relay can simply relay almost[1] any
> template that pays more fees than the previous best template it saw for
> the next block.  That can be more flexible than the current
> implementation of submitblock with package relay which still enforces a
> lot of the rules that helps keep a regular relay node safe from DoS and
> a miner node able to select mineable transactions quickly.
>

Interesting idea! This would also make it easy for external services to try
to do the best possible block building using advanced algorithms. Miners
would just select the best template available from various sources
including nostr.


> A weak block is a block whose header doesn't quite hash to low enough of
> a value to be included on the chain.  It still takes an extraordinary
> amount of hashrate to produce, so it's inherently DoS resistant.  If
> miners are producing block that include transactions not seen by typical
> relay nodes, that can reduce the efficiency and effectiveness of BIP152
> compact block relay, which hurts the profitability of miners of custom
> blocks.  To compensate, miners could relay weak blocks through Nostr to
> full nodes and other miners so that they could quickly relay and accept
> complete blocks that later included the same custom transactions.  This
> would also help fee estimation and provide valuable insights to those
> trying to get their transactions included into the next block.
>

I believe this would be useful right away, wouldn't it? Looking at
mempool.space's block audit, there are definitely blocks that have a
"surprising" content and might take long to download.

The anti-dos measures that you describe for both weak blocks and block
templates seem very robust, but they would require a more intelligent nostr
relay to enforce. Not sure if it is still allowed to call it nostr at that
point. Perhaps it becomes more of a specialised bitcoin relay. btcstr -
"bitcoin stuff transmitted by relays".

Regarding size, the block template and weak block could both be sent in
> BIP152 compact block format as a diff against the expected contents of a
> typical node, allowing Alice to send just a small amount of additional
> data for relay over what she'd have to send anyway for each transaction
> in a package.  (Although it's quite possible that BetterHash or Stratum
> v2 have even better solutions, possibly already implemented.)
>

Sounds like a great way to repurpose what already exists to reduce resource
usage for these additional message types.


> If nothing else, I think Nostr could provide an interesting playground
> for experimenting with various relay and mining ideas we've talked about
> for years, so thanks again for working on this!
>

I think so too! The main question on my mind though is how to actually make
this work. There is a bit of a chicken-egg problem here with users and
miners possibly waiting for each other to adopt.

Joost

--000000000000d8d3f405fce861fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Hi David,<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
A block template is an ordered list of raw transactions that can all be<br>
included in the next block (with some space reserved for a coinbase<br>
transaction).=C2=A0 A full node can validate those transactions and calcula=
te<br>
how much fee they pay.=C2=A0 A Nostr relay can simply relay almost[1] any<b=
r>
template that pays more fees than the previous best template it saw for<br>
the next block.=C2=A0 That can be more flexible than the current<br>
implementation of submitblock with package relay which still enforces a<br>
lot of the rules that helps keep a regular relay node safe from DoS and<br>
a miner node able to select mineable transactions quickly.<br></blockquote>=
<div><br></div><div>Interesting idea! This would also make it easy for exte=
rnal services to try to do the best possible block building using advanced =
algorithms. Miners would just select the best template available from vario=
us sources including nostr.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">
A weak block is a block whose header doesn&#39;t quite hash to low enough o=
f<br>
a value to be included on the chain.=C2=A0 It still takes an extraordinary<=
br>
amount of hashrate to produce, so it&#39;s inherently DoS resistant.=C2=A0 =
If<br>
miners are producing block that include transactions not seen by typical<br=
>
relay nodes, that can reduce the efficiency and effectiveness of BIP152<br>
compact block relay, which hurts the profitability of miners of custom<br>
blocks.=C2=A0 To compensate, miners could relay weak blocks through Nostr t=
o<br>
full nodes and other miners so that they could quickly relay and accept<br>
complete blocks that later included the same custom transactions.=C2=A0 Thi=
s<br>
would also help fee estimation and provide valuable insights to those<br>
trying to get their transactions included into the next block.<br></blockqu=
ote><div><br></div><div>I believe this would be useful right away, wouldn&#=
39;t it? Looking at <a href=3D"http://mempool.space">mempool.space</a>&#39;=
s block audit, there are definitely blocks that have a &quot;surprising&quo=
t; content and might take long to download.</div><div>=C2=A0</div><div>The =
anti-dos measures that you describe for both weak blocks and block template=
s seem very robust, but they would require a more intelligent nostr relay t=
o enforce. Not sure if it is still allowed to call it nostr at that point. =
Perhaps it becomes more of a specialised bitcoin relay. btcstr - &quot;bitc=
oin stuff transmitted by relays&quot;.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
Regarding size, the block template and weak block could both be sent in<br>
BIP152 compact block format as a diff against the expected contents of a<br=
>
typical node, allowing Alice to send just a small amount of additional<br>
data for relay over what she&#39;d have to send anyway for each transaction=
<br>
in a package.=C2=A0 (Although it&#39;s quite possible that BetterHash or St=
ratum<br>
v2 have even better solutions, possibly already implemented.)<br></blockquo=
te><div><br></div><div>Sounds like a great way to repurpose what already ex=
ists to reduce resource usage for these additional message types.</div><div=
>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If nothing else, I think Nostr could provide an interesting playground<br>
for experimenting with various relay and mining ideas we&#39;ve talked abou=
t<br>
for years, so thanks again for working on this!<br></blockquote><div><br></=
div><div>I think so too! The main question on my mind though is how to actu=
ally make this work. There is a bit of a chicken-egg problem here with user=
s and miners possibly waiting for each other to adopt.</div><div><br></div>=
<div>Joost=C2=A0</div></div></div>

--000000000000d8d3f405fce861fc--