path: root/ca/08e79af0a01a52a2c8c18e936ddd09b841b9eb

Return-Path: <burak@buraks.blog>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0275EC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 May 2023 07:54:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D1AB860881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 May 2023 07:54:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D1AB860881
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.004
X-Spam-Level: *
X-Spam-Status: No, score=1.004 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, BITCOIN_XPRIO=1.004, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 b8jr3cJtjr18
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 May 2023 07:54:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B2D1760784
Received: from p3plwbeout22-04.prod.phx3.secureserver.net
 (p3plsmtp22-04-2.prod.phx3.secureserver.net [68.178.252.60])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B2D1760784
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 22 May 2023 07:54:07 +0000 (UTC)
X-MW-NODE: 
X-CMAE-Analysis: v=2.4 cv=Te9TCTch c=1 sm=1 tr=0 ts=646b1f9f
 a=dFffxkGDbYo3ckkjzRcKYg==:117 a=dFffxkGDbYo3ckkjzRcKYg==:17
 a=MX88rfTCAywA:10 a=IeDmx7KLAAAA:8 a=yZVJf90L0lAREZxsrdsA:9 a=QEXdDO2ut3YA:10
 a=0MNkeBRk9KsA:10 a=-FEs8UIgK8oA:10 a=qGpAiAGeD4P_QYEV:21 a=_W_S_7VecoQA:10
 a=DCtRqcNhzEG8Op-OrrPq:22 a=OqTFTPUWgSHX1FSaH1ib:22
X-SECURESERVER-ACCT: burak@buraks.blog
X-SID: 10Mmqc5jA76bs
Date: Mon, 22 May 2023 10:54:03 +0300 (TRT)
From: Burak Keceli <burak@buraks.blog>
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_1516889_1417077939.1684742043880"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v8.12.73
X-Originating-IP: 95.223.74.134
X-Originating-Client: open-xchange-appsuite
X-CMAE-Envelope: MS4xfPLzkDCAQxOdqm2qZMLNH9AoTCJKkyz0dqeBJT50bT13mYz9OZaUZApsWjmDwgfGPeMGTNE5CQUJyDZhzYH76itdAXrsCo8jwQn9uQSnmB4JMDlQhPtT
 T+d6Deco7w3AP0Ge6yf3+sqEiqWXvgQRYdW/y8Ow7JWzJhISiFBTq2YgIdo9CABB3JLwmi49wxLvPRATd2x1l1BS/eboUotDi+t7WifLS98Yl0B44ANpDshl
 hlZejx330ycPW0NAAILjgA==
X-Mailman-Approved-At: Mon, 22 May 2023 09:33:28 +0000
Subject: [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: Mon, 22 May 2023 07:54:10 -0000

------=_Part_1516889_1417077939.1684742043880
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi list,
I'm excited to publicly publish a new second-layer protocol design I've bee=
n working on over the past few months called Ark.
=20
Ark is an alternative second-layer scaling approach that allows the protoco=
l users to send and receive funds without introducing liquidity constraints=
. This means a recipient can get paid without an onboarding setup, such as =
acquiring inbound liquidity. The protocol also consumes orders of magnitude=
 less on-chain footprint than Lightning, as there is no concept of opening =
and closing channels.
=20
Ark has a UTXO set that lives off the chain. These UTXOs are referred to as=
 virtual UTXOs or vTXOs in short. Virtual UTXOs are like short-lived notes =
that expire after four weeks. Users must spend their vTXOs upon receiving t=
hem within this four-week timeframe or return them to themselves to reset t=
he four-week timer. Virtual UTXOs live under a shared UTXO and can be revea=
led on-chain.
=20
When a payment is made on the protocol, existing vTXOs are redeemed, and ne=
w vTXOs are created, similar to how on-chain funds flow. To improve the ano=
nymity set of the coin ownership, vTXOs values are restricted to a set of s=
ats values ranging from one sat to a million sats.
=20
Users can acquire vTXOs from someone who already owns them or use a process=
 called lifting, an atomic two-way peg mechanism that doesn't require trust=
. Lifting lets users lift their on-chain UTXOs off the chain for a 1:1 virt=
ual UTXO. Users can unilaterally redeem a virtual UTXO for an on-chain UTXO=
 without asking for cooperation.=20
=20
When sending funds, users coin-select & destroy their virtual UTXOs and cre=
ate new ones for the recipient (plus change) in an off-chain mixing round. =
Keys for each new virtual UTXO are tweaked with a shared secret that reveal=
s proof of payment when spent. The payment destination is a dedicated well-=
known public key similar to silent payments; however, the payment trace is =
obfuscated through plain tweaking and blinded mixing.
=20
Ark enables anonymous, off-chain payments through an untrusted intermediary=
 called the Ark Service Provider (ASP). ASPs are always-on servers that pro=
vide liquidity to the network and charge liquidity fees, similar to how Lig=
htning service providers work. ASPs on Ark are both (1) liquidity providers=
, (2) blinded coinjoin coordinators, and (3) Lightning service providers. A=
SPs main job is to create rapid, blinded coinjoin sessions every five secon=
ds, also known as pools. A user joins a pool session to make a payment, ini=
tially coin-selecting and registering their vTXOs to spend, registering vTX=
Os for intended recipients, and finally co-signing from their vTXOs to rede=
em them.
=20
Ark can be built on Bitcoin today, but we have to compromise on non-interac=
tivity to do so. Recipients must be online to sign from n-of-n multisig to =
constrain the outputs of a shared UTXO, outputs as in vTXOs. With this appr=
oach, users won=E2=80=99t be able to receive offline payments; they need to=
 self-host an Ark client (like Lightning). To make Ark work without running=
 a server, we need a covenant primitive such as BIP-118 or BIP-119.=20
=20
BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction=
 by hardcoding a 65-byte signature and a 33-byte unknown public key type in=
 a script. Alternatively, BIP-119 CTV can directly constrain transaction ou=
tputs to a template hash. Other alternatives would be (1) TXHASH, (2) CAT +=
 CSFS + TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations.=20
=20
Ark uses a new locktype primitive called txlock to ensure the absolute atom=
icity of a transfer schedule. Txlock is a condition in which only the exist=
ence of a mutually agreed transaction identifier can unlock the condition. =
A txlock condition could be satisfied by a hypothetical opcode called OP_CH=
ECKPREVTXIDFROMTHEUTXOSETVERIFY. However, Ark uses an alternative approach =
to achieving the same outcome using connectors. Connectors are a special ou=
tput type on the protocol. The primitive is that if we want the Bitcoin scr=
ipt to check if a particular transaction id exists, we simply attach an out=
put from that transaction into our spending transaction and check a pre-sig=
ned signature against prevouts of our spending transaction. The connector o=
utpoint in the sighash preimage commits to the transaction id for which we =
want to satisfy the txlock condition. In the Ark context, this is the pool =
transaction containing vTXOs of intended recipients. Txlocks are used in An=
chor Time Locked Contracts (ATLCs) to provide an atomic single-hub payment =
schedule.
=20
Anchor Time Locked Contracts (ATLCs) are conditional payments used on the A=
rk protocol. When a vTXO was created in the first place, an ATLC was attach=
ed to it, similar to how an eltoo:trigger is attached to a funding output d=
uring Eltoo channel formation. When a vTXO is spent, the pre-attached ATLC =
connects to a connector to form a txlock.=20
=20
This txlock formation ensures that, for the attached ATLC to be claimed by =
the service provider, the outpoint context of its connector must remain unc=
hanged. In other words, Ark service providers should not double-spend pool =
transactions they create. This provides an atomic payout construction for s=
enders, as payout vTXOs nest under the same transaction of connectors. The =
link between connectors and newly created vTXOs is obfuscated through blind=
ed mixing between those.
=20
=E2=80=8DPool transactions are created by Ark service providers perpetually=
 every five seconds, which are effectively blinded, footprint-minimal, rapi=
d coinjoin rounds. ASP funds the pool with their own on-chain funds in exch=
ange for vTXOs redemptions. Therefore, the pool transaction that hits on-ch=
ain has only one or a few inputs the ASP provides. The pool transaction has=
 three outputs: vTXOs output, connectors output, and ASP change. Service pr=
oviders place vTXOs for the intended recipients to claim (under the vTXOs o=
utput) and connectors for senders to connect (under the connectors output) =
in their pool transactions.
=20
The first output of the pool transaction, vTXOs output, contains newly crea=
ted vTXOs of the coinjoin round. vTXOs are bundled and nested under this sh=
ared output and can be revealed on-chain. vTXOs output expires four weeks a=
fter its creation, and once it expires, the ASP who funded this output in t=
he first place can solely sweep it. Nested vTXOs under the vTXOs output are=
 expected to be redeemed by their owners in this window period. Nested vTXO=
s may be revealed in this four-week timeframe if the factory operator happe=
ns to be non-collaborative or non-responsive for a long period. Upon reveal=
ing a vTXO, a unilateral exit window can be triggered by attaching the pre-=
signed ATLC, similar to Eltoo. In the optimistic big picture, however, the =
final result is almost always a pool transaction with few inputs and three =
outputs where pool content is rarely revealed on-chain. Therefore, vTXOs & =
connectors remain almost always off the chain.

Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool =
transaction, just like ATLCs and connectors. The attached HTLCs live under =
another shared UTXO called the HTLCs outputs, which also expire after four =
weeks. Ark service providers forward HTLCs to the broader Lightning Network=
 the moment after they them to their pool transaction. This means Ark servi=
ce providers are also Lightning service providers. Ark users can also get p=
aid from Lightning using HTLC-nested vTXOs.
=20
Ark is an open network where anyone can run their own ASP infrastructure. T=
his means a user can have a vTXO set associated with different ASPs. The Ar=
k protocol design allows users to pay lightning invoices from different vTX=
O sources using multi-part payments (MPP). Upon attaching HTLCs (or PTLCs) =
to multiple pools operated by various ASPs, HTLCs can be forwarded to the e=
nd destination via MPP.
=20
A pool transaction can be double-spent by the Ark service provider while it=
 remains in the mempool. However, in the meantime, the recipient can pay a =
lightning invoice with their incoming zero-conf vTXOs, so it=E2=80=99s a fo=
otgun for the service operator to double-spend in this case.=20
=20
A transfer schedule from a sender to a receiver is atomic in nature. ASPs c=
annot redeem senders' vTXOs if they double-spend recipients' vTXOs under th=
e mutually agreed pool transaction id. A future extension of Ark can utiliz=
e a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain t=
he ASP's nonce in their signatures to disincentivize double-spending. Users=
 can forge ASP's signature to claim their previously redeemed vTXOs if a do=
uble-spend occurs in a pool transaction. This is effectively an inbound liq=
uidity-like tradeoff without compromising on the protocol design.
=20
On Ark, payments are credited every five seconds but settled every ten minu=
tes. Payments are credited immediately because users don=E2=80=99t have to =
wait for on-chain confirmations to spend their zero-conf vTXOs further. The=
y can hand over zero-conf vTXOs to others or pay lightning invoices with th=
em. This is because the ASP who can double-spend users' incoming vTXOs is t=
he same ASP who routes Lightning payments.=20
=20
You can find more info at https://arkpill.me/deep-dive https://www.arkpill.=
me/deep-dive.
=20
- Burak
------=_Part_1516889_1417077939.1684742043880
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!doctype html>
<html>
 <head>
  <meta charset=3D"UTF-8">
 </head>
 <body>
  <div class=3D"default-style">
   <div>
    <div>
     <span style=3D"font-weight: 400;">Hi list,</span>
    </div>
    <div>
     <span style=3D"font-weight: 400;">I'm excited to publicly publish a ne=
w second-layer protocol design I've been working on over the past few month=
s called Ark.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark is an alternative second-layer s=
caling approach that allows the protocol users to send and receive funds wi=
thout introducing liquidity constraints. This means a recipient can get pai=
d without an onboarding setup, such as acquiring inbound liquidity. The pro=
tocol also consumes orders of magnitude less on-chain footprint than Lightn=
ing, as there is no concept of opening and closing channels.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark has a UTXO set that lives off th=
e chain. These UTXOs are referred to as virtual UTXOs or vTXOs in short. Vi=
rtual UTXOs are like short-lived notes that expire after four weeks. Users =
must spend their vTXOs upon receiving them within this four-week timeframe =
or return them to themselves to reset the four-week timer. Virtual UTXOs li=
ve under a shared UTXO and can be revealed on-chain.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">When a payment is made on the protoc=
ol, existing vTXOs are redeemed, and new vTXOs are created, similar to how =
on-chain funds flow. To improve the anonymity set of the coin ownership, vT=
XOs values are restricted to a set of sats values ranging from one sat to a=
 million sats.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Users can acquire vTXOs from someone=
 who already owns them or use a process called lifting, an atomic two-way p=
eg mechanism that doesn't require trust. Lifting lets users lift their on-c=
hain UTXOs off the chain for a 1:1 virtual UTXO. Users can unilaterally red=
eem a virtual UTXO for an on-chain UTXO without asking for cooperation.&nbs=
p;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">When sending funds, users coin-selec=
t &amp; destroy their virtual UTXOs and create new ones for the recipient (=
plus change) in an off-chain mixing round. Keys for each new virtual UTXO a=
re tweaked with a shared secret that reveals proof of payment when spent. T=
he payment destination is a dedicated well-known public key similar to sile=
nt payments; however, the payment trace is obfuscated through plain tweakin=
g and blinded mixing.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark enables anonymous, off-chain pay=
ments through an untrusted intermediary called the Ark Service Provider (AS=
P). ASPs are always-on servers that provide liquidity to the network and ch=
arge liquidity fees, similar to how Lightning service providers work. ASPs =
on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators,=
 and (3) Lightning service providers. ASPs main job is to create rapid, bli=
nded coinjoin sessions every five seconds, also known as pools. A user join=
s a pool session to make a payment, initially coin-selecting and registerin=
g their vTXOs to spend, registering vTXOs for intended recipients, and fina=
lly co-signing from their vTXOs to redeem them.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark can be built on Bitcoin today, b=
ut we have to compromise on non-interactivity to do so. Recipients must be =
online to sign from n-of-n multisig to constrain the outputs of a shared UT=
XO, outputs as in vTXOs. With this approach, users won=E2=80=99t be able to=
 receive offline payments; they need to self-host an Ark client (like Light=
ning). To make Ark work without running a server, we need a covenant primit=
ive such as BIP-118 or BIP-119.&nbsp;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">BIP-118 ANYPREVOUTANYSCRIPT can cons=
train outputs of a spending transaction by hardcoding a 65-byte signature a=
nd a 33-byte unknown public key type in a script. Alternatively, BIP-119 CT=
V can directly constrain transaction outputs to a template hash. Other alte=
rnatives would be (1) TXHASH, (2) CAT + CSFS + TAGGEDHASH, or (3) XOR + CSF=
S + TAGGEDHASH combinations.&nbsp;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark uses a new locktype primitive ca=
lled txlock to ensure the absolute atomicity of a transfer schedule. Txlock=
 is a condition in which only the existence of a mutually agreed transactio=
n identifier can unlock the condition. A txlock condition could be satisfie=
d by a hypothetical opcode called OP_CHECKPREVTXIDFROMTHEUTXOSETVERIFY. How=
ever, Ark uses an alternative approach to achieving the same outcome using =
connectors. Connectors are a special output type on the protocol. The primi=
tive is that if we want the Bitcoin script to check if a particular transac=
tion id exists, we simply attach an output from that transaction into our s=
pending transaction and check a pre-signed signature against prevouts of ou=
r spending transaction. The connector outpoint in the sighash preimage comm=
its to the transaction id for which we want to satisfy the txlock condition=
. In the Ark context, this is the pool transaction containing vTXOs of inte=
nded recipients. Txlocks are used in Anchor Time Locked Contracts (ATLCs) t=
o provide an atomic single-hub payment schedule.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Anchor Time Locked Contracts (ATLCs)=
 are conditional payments used on the Ark protocol. When a vTXO was created=
 in the first place, an ATLC was attached to it, similar to how an eltoo:tr=
igger is attached to a funding output during Eltoo channel formation. When =
a vTXO is spent, the pre-attached ATLC connects to a connector to form a tx=
lock.&nbsp;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">This txlock formation ensures that, =
for the attached ATLC to be claimed by the service provider, the outpoint c=
ontext of its connector must remain unchanged. In other words, Ark service =
providers should not double-spend pool transactions they create. This provi=
des an atomic payout construction for senders, as payout vTXOs nest under t=
he same transaction of connectors. The link between connectors and newly cr=
eated vTXOs is obfuscated through blinded mixing between those.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">=E2=80=8DPool transactions are creat=
ed by Ark service providers perpetually every five seconds, which are effec=
tively blinded, footprint-minimal, rapid coinjoin rounds. ASP funds the poo=
l with their own on-chain funds in exchange for vTXOs redemptions. Therefor=
e, the pool transaction that hits on-chain has only one or a few inputs the=
 ASP provides. The pool transaction has three outputs: vTXOs output, connec=
tors output, and ASP change. Service providers place vTXOs for the intended=
 recipients to claim (under the vTXOs output) and connectors for senders to=
 connect (under the connectors output) in their pool transactions.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">The first output of the pool transac=
tion, vTXOs output, contains newly created vTXOs of the coinjoin round. vTX=
Os are bundled and nested under this shared output and can be revealed on-c=
hain. vTXOs output expires four weeks after its creation, and once it expir=
es, the ASP who funded this output in the first place can solely sweep it. =
Nested vTXOs under the vTXOs output are expected to be redeemed by their ow=
ners in this window period. Nested vTXOs may be revealed in this four-week =
timeframe if the factory operator happens to be non-collaborative or non-re=
sponsive for a long period. Upon revealing a vTXO, a unilateral exit window=
 can be triggered by attaching the pre-signed ATLC, similar to Eltoo. In th=
e optimistic big picture, however, the final result is almost always a pool=
 transaction with few inputs and three outputs where pool content is rarely=
 revealed on-chain. Therefore, vTXOs &amp; connectors remain almost always =
off the chain.</span>
    </div> <br>
    <div>
     <span style=3D"font-weight: 400;">Ark can interoperate with Lightning =
by attaching HTLCs and PTLCs to a pool transaction, just like ATLCs and con=
nectors. The attached HTLCs live under another shared UTXO called the HTLCs=
 outputs, which also expire after four weeks. Ark service providers forward=
 HTLCs to the broader Lightning Network the moment after they them to their=
 pool transaction. This means Ark service providers are also Lightning serv=
ice providers. Ark users can also get paid from Lightning using HTLC-nested=
 vTXOs.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">Ark is an open network where anyone =
can run their own ASP infrastructure. This means a user can have a vTXO set=
 associated with different ASPs. The Ark protocol design allows users to pa=
y lightning invoices from different vTXO sources using multi-part payments =
(MPP). Upon attaching HTLCs (or PTLCs) to multiple pools operated by variou=
s ASPs, HTLCs can be forwarded to the end destination via MPP.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">A pool transaction can be double-spe=
nt by the Ark service provider while it remains in the mempool. However, in=
 the meantime, the recipient can pay a lightning invoice with their incomin=
g zero-conf vTXOs, so it=E2=80=99s a footgun for the service operator to do=
uble-spend in this case.&nbsp;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">A transfer schedule from a sender to=
 a receiver is atomic in nature. ASPs cannot redeem senders' vTXOs if they =
double-spend recipients' vTXOs under the mutually agreed pool transaction i=
d. A future extension of Ark can utilize a hypothetical data manipulation o=
pcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures t=
o disincentivize double-spending. Users can forge ASP's signature to claim =
their previously redeemed vTXOs if a double-spend occurs in a pool transact=
ion. This is effectively an inbound liquidity-like tradeoff without comprom=
ising on the protocol design.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">On Ark, payments are credited every =
five seconds but settled every ten minutes. Payments are credited immediate=
ly because users don=E2=80=99t have to wait for on-chain confirmations to s=
pend their zero-conf vTXOs further. They can hand over zero-conf vTXOs to o=
thers or pay lightning invoices with them. This is because the ASP who can =
double-spend users' incoming vTXOs is the same ASP who routes Lightning pay=
ments.&nbsp;</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">You can find more info at</span><a h=
ref=3D"https://www.arkpill.me/deep-dive"><span style=3D"font-weight: 400;">=
 </span><span style=3D"font-weight: 400;">https://arkpill.me/deep-dive</spa=
n></a><span style=3D"font-weight: 400;">.</span>
    </div>
    <div>
     &nbsp;
    </div>
    <div>
     <span style=3D"font-weight: 400;">- Burak</span>
    </div>
   </div>
  </div>
 </body>
</html>
------=_Part_1516889_1417077939.1684742043880--