path: root/0e/1ff3aebaa2d96a0ea8d44e319a6c9cc7509726

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 246DCC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 13:30:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id F1E2D83443
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 13:30:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F1E2D83443
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=EHJEITpq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.151
X-Spam-Level: 
X-Spam-Status: No, score=0.151 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_ENVFROM_END_DIGIT=0.25, 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 Me1wP9HIbOQW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 13:30:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 85F728203B
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [IPv6:2a00:1450:4864:20::52c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 85F728203B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 13:30:45 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-51491b87565so5767296a12.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 May 2023 06:30:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685453443; x=1688045443;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=YkJAKpbrXZ6LUL5mjJFblhBXIe/D9yQ2eefaTqi0Ooc=;
 b=EHJEITpqtg15g91ak2cDPAymOT9lSEjzvAAj5+09Dh7jUIR/MRRQCSyENVC3v1vy49
 hGA9JOImEP4A3QRVZR9SpWamn2YqhvyfWlJvkU6siuziECNqN3K0k/2Lr77ThvD7T6wk
 COXWr94dTJPUoOFiuubEqFLWulLEErdLzUjZqrbnk971vGb2lDYDfi95NUzZMDxAAQG3
 p1I3k2a/i+JDqR/kKNLVrekdvOGAqWMaL6fJMyl99a2OVQsIC1JxSG3sxNlc2xA480ti
 FaYSqbR9MhKWemtwXCIbazPPYfFH0n/BrOyqp5ZbQmim7ZiXFsSjfx+16DUyz9PVq9Bk
 SeDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685453443; x=1688045443;
 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=YkJAKpbrXZ6LUL5mjJFblhBXIe/D9yQ2eefaTqi0Ooc=;
 b=iUFOOXuOFWTMJwMBQdIoRjQHJrxDYUSqa64BXI3tMF6k+q4lQZz0jMsfBs7YHUEgvI
 KWytSoucJKXJaK2JhvNWpv4parNqKLAuk0xGr2x/XXdInIL/KnrB7WYmkdXxWQjQw7hq
 YlerxTxniWPquAfgp4mb7GTSMGmMhZ/pBa2oGYQVIuSLZzPGSib4rw8+ft8MkG81FfcF
 JtCgw4OJ0uDviueRBdQMBibFDz0lJTEjlxuvfqJsPaVCXDvsWCk5Xz+STh6ffQHwOc91
 1sRsBcSXGYdcL1O3Dstt5V11RS8OMCao/r837TGkXxKzlf5AR7ckX409+tLMkJElxXbf
 ERoQ==
X-Gm-Message-State: AC+VfDyw3uASSCU/qVvzbD6soT95sPG2++KGsRBOPT1bbDzQ08YClOI9
 wYhq6RFpncQTOFGV2f0lBhVWG122mZ3POpU0+AI=
X-Google-Smtp-Source: ACHHUZ5b+2jTp7ieYn5m7dmHWShOsYIESH0PuEakKzf19B7AyByEDBMx123wfmWxf0o4VFid4dBgHPRqaaivXu5Gw9Q=
X-Received: by 2002:a17:907:ea6:b0:96f:d154:54f7 with SMTP id
 ho38-20020a1709070ea600b0096fd15454f7mr2245116ejc.42.1685453443362; Tue, 30
 May 2023 06:30:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
 <020c50422fb4bc03fe1d6f06c2ae751f@dtrt.org>
 <CAJBJmV-=berWDEeXfLcfyqQQPL5m32St9XUd02bTXJVOHZsM+Q@mail.gmail.com>
In-Reply-To: <CAJBJmV-=berWDEeXfLcfyqQQPL5m32St9XUd02bTXJVOHZsM+Q@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 30 May 2023 09:30:32 -0400
Message-ID: <CAB3F3DuoOdTAypfqptU94E_j4oNJuBwZHPifo8mmDxTOaSeyNQ@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c6f50805fce93585"
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 13:30:47 -0000

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

Hi Joost, David,

In my mind, weak blocks' main benefit would be that it improves block relay
by giving PoW-hints on what are in miner's mempools. Non-standard
transactions could even be cached(even if not validated until block
inclusion), which would tolerate more heterogeneity in policies without
drastically increasing relay times. Of course, it can also have the side
effect of gossiping better transaction packages, though I think this would
be a ton of work to really take advantage of. Perhaps we might be able to
do better in a post-cluster-mempool world, gossiping chunks.

At present I think energy would be best spent writing a weak blocks BIP
proposal, since one has never been written before(?), and it would be
fairly trivial to swap out p2p things with RPC calls if so desired for fast
experimentation over alternative relays.

Cheers,
Greg



On Tue, May 30, 2023 at 8:58=E2=80=AFAM Joost Jager via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 nos=
tr
> relay to enforce. Not sure if it is still allowed to call it nostr at tha=
t
> 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 a=
nd
> miners possibly waiting for each other to adopt.
>
> Joost
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Joost, David,<div><br></div><div>In my mind, weak block=
s&#39; main benefit would be that it improves block relay by giving PoW-hin=
ts on what are in miner&#39;s mempools. Non-standard transactions could eve=
n be cached(even if not validated until block inclusion), which would toler=
ate more heterogeneity=C2=A0in policies without drastically increasing rela=
y times. Of course, it can also have the side effect of gossiping better tr=
ansaction packages, though I think this would be a ton of work to really ta=
ke advantage of. Perhaps we might be able to do better in a post-cluster-me=
mpool world, gossiping chunks.</div><div><br></div><div>At present I think =
energy would be best spent writing a weak blocks BIP proposal, since one ha=
s never been written before(?), and it would be fairly trivial to swap out =
p2p things with RPC calls if so desired for fast experimentation over alter=
native relays.</div><div><br></div><div>Cheers,</div><div>Greg</div><div><b=
r></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, May 30, 2023 at 8:58=E2=80=AFAM Joost Jager =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_quote"><div>Hi David,<br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-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" target=3D"_blank">memp=
ool.space</a>&#39;s block audit, there are definitely blocks that have a &q=
uot;surprising&quot; 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 templates seem very robust, but they would require a more intelli=
gent nostr relay to enforce. Not sure if it is still allowed to call it nos=
tr at that point. Perhaps it becomes more of a specialised bitcoin relay. b=
tcstr - &quot;bitcoin stuff transmitted by relays&quot;.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c6f50805fce93585--