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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Return-Path: <joost.jager@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2B01CC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2023 15:27:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EBF7460EAB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2023 15:27:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EBF7460EAB
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=J5TMw6PV
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EhN1dDZ5sayS
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2023 15:26:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F267660C33
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
[IPv6:2a00:1450:4864:20::52c])
by smtp3.osuosl.org (Postfix) with ESMTPS id F267660C33
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2023 15:26:56 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id
4fb4d7f45d1cf-50bcb229adaso1909092a12.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 May 2023 08:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1684855615; x=1687447615;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=JUfbi7Qa+ihvvIrIL5+F0eIsTgmosLp62z/lDGtOnzw=;
b=J5TMw6PV/eZ4zZ2/+cX6nnXPepuAxCGYcP07gyowPFROmWTXzI1+zq2Y5VkgXWRBs7
9w3B+K7nwp5NZX6u18559TFISl8ZCFM+po3Z5weaPOVIHQHwDw/yC9uzhNgF1xi78Uxx
AIhsIfKoWS1Mzlrb/pvELktdc4ITi+EBjXs32yEy4vJb0PXj0+MOAIJ8IXwwx5Ig9YjT
sgWZTu74vH1kS5dKcLH1v0oWRD9Iz29q/41yS5MkecPwvcOuiXyAa6CZpN5AvlG8LYru
CvbWxG0/pL4BvnvrUB5ZRaRa8cWl/EM+8wR32F8IHSbvk6Ar8Kv6eTCC09XsUhkGFblm
OsQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1684855615; x=1687447615;
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=JUfbi7Qa+ihvvIrIL5+F0eIsTgmosLp62z/lDGtOnzw=;
b=UP9+zJNvSIfcl7vxYw8U27mImZtJoRxSvkp0/Qc3o/DcExh34Cx/PgoW8cKwh98+nO
fIX7H54prZX5G5/qlvLEpXJFsKBCtd/RiJPIf+6z7Us+OAZ6AEe5yZXWUpm6uxypZaZx
ii66JGDYKYH2GkfCmN2glDHO1owXteaFwwK7910xzIF+ADNLhAGaYdkqY9BnSo03dxyd
yzk7+iAX8eNn8eKNDZuFetzgNhq3l78eEeiZbALyG/7eKID8PU45rDB3oHvNFRlQaPMk
w0tJZ9MXYDuv2c+RptN9s8tw2oLa0bGyJCR2WMPMaaJL9QSC/gWmTa0sFp05TDRqlx+F
jSBg==
X-Gm-Message-State: AC+VfDx0bIIPvhnVY/SVdWNdtVJo6DMyGeU0G1K9Z7eY9WvQlIoJsfWI
KBXj4XL8wbmjYtPEldIAKm49BNbwROwxTPsgN+I=
X-Google-Smtp-Source: ACHHUZ4oegYlJmgFLZW3MkaFptlMhtdj0W8S7YPMbxpPuJ///svQGu1T0w6932dO0xW10cngMNo35b2LUqYq+3W1F9Y=
X-Received: by 2002:a17:907:a01:b0:949:cb6a:b6f7 with SMTP id
bb1-20020a1709070a0100b00949cb6ab6f7mr13039688ejc.56.1684855614638; Tue, 23
May 2023 08:26:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV932eeuiBzo_EMxJ1iU=Gave9=PC3U7seVoBXUFsu_GUA@mail.gmail.com>
<FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com>
In-Reply-To: <FVGoJA8LiudZ3BF2LRmy1w2tF-8IpZDKA49w56skRoerZ96j-qkxw-DUjSxZ3m-APMI_V-Wojn-rD3juO3IcBYRNAh9JwKFlyDWz3vwERS0=@protonmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Tue, 23 May 2023 17:26:18 +0200
Message-ID: <CAJBJmV9sCCtyWS=yXuj9uG15t+d+hCcB-CrkNXL-Tk1UdaXVFg@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000688fac05fc5e04a7"
X-Mailman-Approved-At: Tue, 23 May 2023 15:47:05 +0000
Cc: 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, 23 May 2023 15:27:02 -0000
--000000000000688fac05fc5e04a7
Content-Type: text/plain; charset="UTF-8"
Hi fd0,
> - Transactions could be encrypted when published as nostr events initially
> except size, fee rate and offer. This can be used by different clients to
> show them as external mempool with transactions sorted by fee rate without
> affecting privacy of users.
>
I don't think this will work because those encrypted transactions could all
be fake and distort the view clients have on this 'mempool'?
> - Mining pools will be incentivized to include these transaction in their
> blocks if they are using a higher fee rate compared to transactions in
> normal mempool used by bitcoin nodes or there is a mechanism to accept
> published offers, NIP4 is used to privately coordinate everything between
> user and pool. User can lock some sats in a 2of2 multisig and release it to
> mining pool on confirmation.
>
I believe you are suggesting out-of-band payment in case the fee included
in the transaction itself is insufficient and CPFP/RBF is impossible or
impractical? The question is why would the miner trust you to indeed
release after confirmation? The 2-of-2 presumably has a clawback clause
with a timeout that could be used by the user to avoid paying.
Joost
--000000000000688fac05fc5e04a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi fd0,</div><div><br></div><div class=3D"gmail_quote=
"><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"><br>
- Transactions could be encrypted when published as nostr events initially =
except size, fee rate and offer. This can be used by different clients to s=
how them as external mempool with transactions sorted by fee rate without a=
ffecting privacy of users.<br></blockquote><div><br></div><div>I don't =
think this will work because those encrypted transactions could all be fake=
and distort the view clients have on this 'mempool'?</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Mining pools will be incentivized to include these transaction in their b=
locks if they are using a higher fee rate compared to transactions in norma=
l mempool used by bitcoin nodes or there is a mechanism to accept published=
offers, NIP4 is used to privately coordinate everything between user and p=
ool. User can lock some sats in a 2of2 multisig and release it to mining po=
ol on confirmation.<br></blockquote><div><br></div><div>I believe you are s=
uggesting out-of-band payment in case the fee included in the transaction i=
tself is insufficient and CPFP/RBF is impossible or impractical?=C2=A0The q=
uestion is why would the miner trust you to indeed release after confirmati=
on? The 2-of-2 presumably has a clawback clause with a timeout that could b=
e used by the user to avoid paying.</div><div><br></div><div>Joost</div></d=
iv></div>
--000000000000688fac05fc5e04a7--
|
