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
155
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B2B79C0174
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Feb 2020 03:41:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id A058420368
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Feb 2020 03:41:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vTWJc-iCYRMd
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Feb 2020 03:41:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by silver.osuosl.org (Postfix) with ESMTPS id 6545620365
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Feb 2020 03:41:32 +0000 (UTC)
Received: from [69.59.18.158] (unknown [69.59.18.158])
by mail.as397444.net (Postfix) with ESMTPSA id 6174F191C4F;
Mon, 3 Feb 2020 03:41:29 +0000 (UTC)
Content-Type: multipart/alternative;
boundary=Apple-Mail-DFCC224C-B9FA-44FD-A8CF-3959F09DF76A
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 2 Feb 2020 19:41:21 -0800
Message-Id: <AE891071-666A-466F-A8F2-4A15A6C0D700@mattcorallo.com>
References: <CAPc0aKFuE9RVHj0i3k_C+Lc3dyqk6m4+zvq=JG+51TUgUMFz5w@mail.gmail.com>
In-Reply-To: <CAPc0aKFuE9RVHj0i3k_C+Lc3dyqk6m4+zvq=JG+51TUgUMFz5w@mail.gmail.com>
To: Anas <maimtiaz@bu.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17C54)
Subject: Re: [bitcoin-dev] Characterizing orphan transaction in the Bitcoin
network
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: Mon, 03 Feb 2020 03:41:33 -0000
--Apple-Mail-DFCC224C-B9FA-44FD-A8CF-3959F09DF76A
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
The orphan pool has nontrivial denial of service properties around transacti=
on validation. In general, I think the goal has been to reduce/remove it, no=
t the other way around. In any case, this is likely the wrong forum for soft=
ware-level discussion of Bitcoin Core. For that, you probably want to open a=
n issue on github.com/bitcoin/bitcoin.
Matt
> On Feb 1, 2020, at 14:12, Anas via bitcoin-dev <bitcoin-dev@lists.linuxfou=
ndation.org> wrote:
>=20
> =EF=BB=BF
> Hi all,
>=20
> This paper - https://arxiv.org/pdf/1912.11541.pdf - characterizes orphan t=
ransactions in the Bitcoin network and shows that increasing the size of the=
orphan pool reduces network overhead with almost no additional performance o=
verhead. What are your thoughts?
>=20
> Abstract:=20
>> Orphan transactions are those whose parental income-sources are missing a=
t the time that they are processed. These transactions are not propagated to=
other nodes until all of their missing parents are received, and they thus e=
nd up languishing in a local buffer until evicted or their parents are found=
. Although there has been little work in the literature on characterizing th=
e nature and impact of such orphans, it is intuitive that they may affect th=
roughput on the Bitcoin network. This work thus seeks to methodically resear=
ch such effects through a measurement campaign of orphan transactions on liv=
e Bitcoin nodes. Our data show that, surprisingly, orphan transactions tend t=
o have fewer parents on average than non-orphan transactions. Moreover, the s=
alient features of their missing parents are a lower fee and larger size tha=
n their non-orphan counterparts, resulting in a lower transaction fee per by=
te. Finally, we note that the network overhead incurred by these orphan tran=
sactions can be significant, exceeding 17% when using the default orphan mem=
ory pool size (100 transactions). However, this overhead can be made negligi=
ble, without significant computational or memory demands, if the pool size i=
s merely increased to 1000 transactions.
>=20
> Regards,
> Anas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-DFCC224C-B9FA-44FD-A8CF-3959F09DF76A
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">The orphan pool has nontri=
vial denial of service properties around transaction validation. In general,=
I think the goal has been to reduce/remove it, not the other way around. In=
any case, this is likely the wrong forum for software-level discussion of B=
itcoin Core. For that, you probably want to open an issue on github.com/bitc=
oin/bitcoin.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Matt</div><div=
dir=3D"ltr"><br><blockquote type=3D"cite">On Feb 1, 2020, at 14:12, Anas vi=
a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<br><br></=
blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div di=
r=3D"ltr">Hi all,<div><br></div><div>This paper - <a href=3D"https://ar=
xiv.org/pdf/1912.11541.pdf">https://arxiv.org/pdf/1912.11541.pdf</a> -&=
nbsp;characterizes orphan transactions in the Bitcoin network and shows=
that increasing the size of the orphan pool reduces network overhead with a=
lmost no additional performance overhead. What are your thoughts?</div><div>=
<br></div><div>Abstract: </div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><span style=3D"color:rgb(0,0,0);font-family:"Lucida Grande"=
,helvetica,arial,verdana,sans-serif;font-size:13.608px">Orphan transactions a=
re those whose parental income-sources are missing at the time that they are=
processed. These transactions are not propagated to other nodes until all o=
f their missing parents are received, and they thus end up languishing in a l=
ocal buffer until evicted or their parents are found. Although there has bee=
n little work in the literature on characterizing the nature and impact of s=
uch orphans, it is intuitive that they may affect throughput on the Bitcoin n=
etwork. This work thus seeks to methodically research such effects through a=
measurement campaign of orphan transactions on live Bitcoin nodes. Our data=
show that, surprisingly, orphan transactions tend to have fewer parents on a=
verage than non-orphan transactions. Moreover, the salient features of their=
missing parents are a lower fee and larger size than their non-orphan count=
erparts, resulting in a lower transaction fee per byte. Finally, we note tha=
t the network overhead incurred by these orphan transactions can be signific=
ant, exceeding 17% when using the default orphan memory pool size (100 trans=
actions). However, this overhead can be made negligible, without significant=
computational or memory demands, if the pool size is merely increased to 10=
00 transactions.</span></blockquote><div><span style=3D"color:rgb(0,0,0);fon=
t-family:"Lucida Grande",helvetica,arial,verdana,sans-serif;font-s=
ize:13.608px"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-fam=
ily:"Lucida Grande",helvetica,arial,verdana,sans-serif;font-size:1=
3.608px">Regards,</span></div><div><span style=3D"color:rgb(0,0,0);font-fami=
ly:"Lucida Grande",helvetica,arial,verdana,sans-serif;font-size:13=
.608px">Anas</span></div></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=
--Apple-Mail-DFCC224C-B9FA-44FD-A8CF-3959F09DF76A--
|
