1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id AFFE6C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2023 02:37:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 717DC402F3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2023 02:37:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 717DC402F3
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id cQwrecdNPg2O
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2023 02:37:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 841A840184
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 841A840184
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2023 02:37:15 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id D23932800860;
Sat, 27 May 2023 19:37:12 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Sat, 27 May 2023 19:37:12 -0700 (PDT)
MIME-Version: 1.0
Date: Sat, 27 May 2023 16:37:12 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Joost Jager <joost.jager@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <020c50422fb4bc03fe1d6f06c2ae751f@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 828.6472be58.66d7c.0
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: Sun, 28 May 2023 02:37:17 -0000
On 2023-05-22 21:19, Joost Jager via bitcoin-dev wrote:
> A notable advantage of this approach is that it delegates the
> responsibility of dealing with Denial-of-Service (DoS) threats to the
> relays themselves. They could, for example, require a payment to
> mitigate such concerns.
Hi Joost,
Thanks for working on this! One quick thought I had was that a possibly
interesting avenue for exploration would be that, in addition to
relaying individual transactions or packages, it might be worth relaying
block templates and weak blocks as both of those provide inherent DoS
resistance and can offer useful features.
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.
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.
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.)
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!
-Dave
[1] In addition to validating transactions, a relay would probably want
to reject templates that contained transactions that took
excessively long to validate (which could cause a block including
them to become stale) or that included features reserved for
upgrades (as a soft fork that happened before the relay's node was
upgraded might make that block invalid).
|
