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
|
Return-Path: <rx@awsomnet.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2BB55C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 20:20:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id F3306424E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 20:20:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F3306424E1
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=awsomnet-org.20221208.gappssmtp.com
header.i=@awsomnet-org.20221208.gappssmtp.com header.a=rsa-sha256
header.s=20221208 header.b=dQWR0XIp
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id LULwSYXNyhO7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 20:20:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 63180424DE
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com
[IPv6:2607:f8b0:4864:20::b36])
by smtp4.osuosl.org (Postfix) with ESMTPS id 63180424DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 20:20:47 +0000 (UTC)
Received: by mail-yb1-xb36.google.com with SMTP id
3f1490d57ef6-ba8374001abso1956844276.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2023 13:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=awsomnet-org.20221208.gappssmtp.com; s=20221208; t=1684959646; x=1687551646;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=HkuO+iEfx7YUpXCA6740pmc30A1JqbrhiLqkJgl9PYA=;
b=dQWR0XIpBvyYxZKY6zW5Bjipgbhyhz/b0dbBUB1NfaIgUdAsPhvMcX3JESWgniaWdU
iVl9aDE4OMDr/DTbOnpddl8HikKK5+yvRROJCG70eqRk3t5zQ56jI+qpLobQqe6f7Lpq
ao+mxPSqkbyuJem3ujeyUlbtqKBzA22TBEFWLXMKtbQ8MzgpeqS5yPA/CzeMOdhUJltS
Q0kUBUIsGmefv7uufO9U2D8s75I6dULF6NT94X0rwd/rl4zp+y9XqA9tUGVamGozG4FX
MeA4g6pVdGwcRK4kKxHPU+HqKAjfsadwwGCDEMGlBixvKrGmzqDwFYd0WQbG1XwDDVbZ
wu9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1684959646; x=1687551646;
h=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=HkuO+iEfx7YUpXCA6740pmc30A1JqbrhiLqkJgl9PYA=;
b=D4lrLt/QguuUcdMKoZ+vNiPfC8PpwWQ2Cc4j8SDPfVJEF4VjlVSJelAMt6oy4gYUe8
dRkSljfgelP1VkFBDYeXUpfRP0a6SFptd1J0GbMt4PWnuXcDuS6jRuqB6YI/ddd7Zw3z
0S2wSqkdNp7/sdLwcBuQ8yHjc6leGfgiH8eorShIl6/0diI53PghyF2vU605W7XD+OUV
qEqkq4eI79xHCuDsG6AMpNe8BSqF907u+ZedYn4flQjU9jpVxxDMZrmJ4tbPyOzkqY69
d3LZO3sjpnCT99Eb9wT3lrWLsMRdwEzboLoIHr+8npVeIy2p/AzV+vKlXP5cDNLVhahW
ZsDA==
X-Gm-Message-State: AC+VfDwXH37CrDAmc+mB/BeUSnOpXiXex3V/zgnVPEl7AJGMHmsfvnFo
lyILTIHshbFWira3E8UM3Iuy42uI3sJwMDs441cX26/FLgNclxmr
X-Google-Smtp-Source: ACHHUZ7jtdiBW0D5vw9WYhuSqA6t/vaegix3tZS4yB29XI+zvAbfLXHB+JPUGm04xVu5VfeXfBZeFQyaL88yKWULHdo=
X-Received: by 2002:a81:60c1:0:b0:565:798b:949e with SMTP id
u184-20020a8160c1000000b00565798b949emr2167094ywb.20.1684959646259; Wed, 24
May 2023 13:20:46 -0700 (PDT)
MIME-Version: 1.0
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
In-Reply-To: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
From: adiabat <rx@awsomnet.org>
Date: Wed, 24 May 2023 16:20:35 -0400
Message-ID: <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=hfwsxLgwWkUw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
Layer Solution
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: Wed, 24 May 2023 20:20:49 -0000
Hi - thanks for the Ark write up; I have a bunch of questions but here's 2:
---
Q1:
"Pool transactions are created by ark service providers perpetually
every 5 seconds"
What exactly happens every 5 seconds? From the 15.44.21-p-1080.png
diagram [1], a pool transaction is a bitcoin transaction, with all the
inputs coming from the ASP. My understanding is that every 5 seconds,
we progress from PoolTx(N) to PoolTx(N+1). Does the ASP sign a new
transaction which spends the same ASP funding inputs as the previous
pool transaction, which is a double spend or fee bump? Or does it
spend the outputs from the previous PoolTx?
In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending
the same inputs (call this method A), or does PoolTx(2) spend an
output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for
PoolTx(2) to become valid (method B)? Or are they completely separate
transactions with unconflicting inputs (method C)?
When the ASP creates a pool transaction, what do they do with it? Do
they broadcast it to the gossip network? Or share it with other pool
participants?
With method A, if the ASP shares pool transactions with other people,
there Doesn't seem to be any way to ensure which PoolTx gets
confirmed, invalidating all the other ones. They're all valid so
whichever gets into a block first wins.
With method B, there seems to be a large on-chain load, with ~120
chained transactions trying to get in every block. This wouldn't play
nicely with mempool standardness and doesn't seem like you could ever
"catch up".
With method C, ASPs would need a pretty large number of inputs but
could recycle them as blocks confirm. It would cost a lot but maybe
could work.
---
Q2:
The other part I'm missing is: what prevents the ASP from taking all
the money? Before even getting to vTXOs and connector outputs, from
the diagram there are only ASP inputs funding the pool transaction.
If the pool transaction is confirmed, the vTXOs are locked in place,
since the vTXO output cannot be changed and commits to all
"constrained outs" via OP_CTV. If the pool transaction is
unconfirmed, the ASP can create & sign a transaction spending all ASP
funding inputs sending the money back to the ASP, or anywhere else.
In this case, users don't have any assurance that their vTXO can ever
turn into a real UTXO; the ASP can "rug-pull" at any time, taking all
the money in the pool. Adding other inputs not controlled by the ASP
to the transaction wouldn't seem to fix the problem, because then any
user removing their inputs would cancel the whole transaction.
More detail about how these transactions work would be appreciated, thanks!
-Tadge
[1] https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png
|
