path: root/98/e3dd7cd643679ed766583b5124d7c1ca4a7a64

Return-Path: <rsomsen@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7D9E0C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 09:58:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 6292D204A0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 09:58:44 +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 x1NdBmJMRWVP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 09:58:42 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com
 [209.85.218.65])
 by silver.osuosl.org (Postfix) with ESMTPS id 181DC2038F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 09:58:42 +0000 (UTC)
Received: by mail-ej1-f65.google.com with SMTP id o10so13686087ejn.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 02:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=qXWEQ5vFT5bPqm4yU2hA0i+A2McHgT8g70/kPlRb6M0=;
 b=qO+rRNzyhQi6T5GTujbNC9NNREvSvA5ZxSaN9NSdk2phpvdsZ6429rWDNWXaWxhOk8
 J/FwPz9s8dMascrh41YNAnqNEOEms/eGmxtZC7z3x+8nF6u77vmUz6+6Kt32ElA/mZuY
 s57ZSQQ7B46ea1/MLmsgDRmYFNFiG/k2QE8cPVM8pblYvLYjGrMFvBBqtzrBDyyBJfgu
 YWsi9Qc3JIMT/5QwR2JHt2ompopxFiDcR1z700BL1hjnfjqEA9bUCPcNeHp/zIWPNeuY
 uM2CEUt/J8XcWmEuehUE3frYqT9wUYo9379f7rPCPUB4YlxTKQRTbfzwdBYZjTBvOz6t
 P5aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=qXWEQ5vFT5bPqm4yU2hA0i+A2McHgT8g70/kPlRb6M0=;
 b=Me9wgENIpU6uzfPjRTrPQlB4hsuXECjatmgaB0VJSK84EsSHpqkU1+ajjzJusd04lW
 3ilxoj64OWydpxRlXfVd2R+pGxBatcIPSjmVkFhRQqHmtmRoumCRccspopkOcmjmF1Fz
 sXzhbM5ALOgtKFifCYa4ZaFgXqJVT39l46sKg72/jDwoJaXyBAr+h2GvIiVNx5CYhWIv
 4FfCkBAJ49bqDxn1HIe+LK41Z8QQa3jPZjeiOwY7WRymUBoMBEigbgOC649LrEOTAHCm
 dzkBXk/SLy7R3MUNyEU2cEfOsK8/h12oNzF3u9ffXgT37kzH0fN1Doex3rRlgwO4NxJR
 /VPA==
X-Gm-Message-State: AGi0PuYaPA0xhhNJZ92X7ZLsIQK3g7+jgfdvYXtl4aWjyc6z5Ybq3oLa
 72ywQ3KECX3e2lszbsFeJXHLkVZbudoCEpZjicJ/oN1h
X-Google-Smtp-Source: APiQypJzopGjYyHvkNyhmoR/QWnrSOTUOVkq1Dbf3aoUTUkfVFxiIIIJMUDWfdxPPVZKFeFfZVj8nzDh70PnUEJaPk8=
X-Received: by 2002:a17:906:304d:: with SMTP id
 d13mr20232808ejd.159.1589363920204; 
 Wed, 13 May 2020 02:58:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
 <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
 <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
 <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
 <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
 <CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
In-Reply-To: <CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 13 May 2020 11:58:26 +0200
Message-ID: <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e1fb3005a5849f07"
X-Mailman-Approved-At: Wed, 13 May 2020 09:59:30 +0000
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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, 13 May 2020 09:58:44 -0000

--000000000000e1fb3005a5849f07
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

>potentially both Alice and Bob know all the secrets on the LTC side and
end up competing over it

That's exactly right.

>Bob can thus give a copy of the revoke tx with signature directly to its
favorite miner, forcing Alice to take 3 transactions

Note that the timelock on the revoke tx is longer than the timelock on
refund tx #1. The idea is that Alice aborts the protocol by publishing
refund tx #1 if the protocol hasn't reached step 4 in the svg by the time
it becomes valid. This should entirely mitigate the issue you're describing.

>adding two CPFP outputs (one for each participant)

There seems to be a situation where RBF can be disabled by the other party,
but I'm not sure I see it... Why would a single output spendable by either
key be insufficient?

>We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well

Allowing others to add inputs/outputs would introduce malleability. Refund
tx #2 and the timeout tx would become invalid.

>Bob cannot safely perform step 2 before getting both signatures for the
revoke tx

That's right, as you guessed, he does receive a copy of the signed revoke
tx at protocol start.

>>alternatively Bob can just spend before the timelock expires.
>This seems to be the safest alternative

I agree not giving Alice time to publish the revoke tx is safest, but one
does not preclude the other. The revoke tx is on an absolute timelock, so
spending it before that time means you don't have anything to worry about,
and spending it later means you'll have to be online and keep an eye out.
If staying online is not a problem, then fee wise that seems preferable. As
long as less than half of all valid (i.e. the timelock was reached) revoke
transactions get broadcast, you'll be saving on fees.

Cheers,
Ruben

On Wed, May 13, 2020 at 11:57 AM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi Chris,
>
> Thanks for taking a look :)
>
> >it also improves privacy because the coins could stay unspend for a long
> time, potentially indefinitely
>
> Excellent point. The pre-swap setup transactions would still be subject to
> timing/amount analysis, but it's clearly a lot less problematic than the
> traditional 4 tx swap. And Payswap may be able to mitigate the amount
> analysis.
>
> >Using relative timelocks and private key handover for old-style coinswaps
> would give us the same two-transaction effect
>
> I agree, Lloyd pointed out the same thing. One thing to add is that such a
> setup would result in four on-chain transactions if the protocol is
> aborted, due to the need to invalidate the refund transaction.
>
> >the idea of private key handover was mentioned as early as 2016 in the
> original Lightning Network paper
>
> Interesting! Thanks for pointing that out.
>
> Cheers,
> Ruben
>
> On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>> Good morning Ruben,
>>
>> > >If the shortened refund transaction exists (labeled "refund
>> transaction #1" in the SVG) then the same issue still occurs
>> >
>> > Yes, but there is one crucial difference: at that point in the protocol
>> (Bob has the success transaction and then stops cooperating) Alice and Bob
>> both had the opportunity not to take that path. Bob could have sent the
>> success transaction, and Alice could have waited and sent the revoke
>> transaction. They would essentially be "colluding" to fail.
>>
>> Okay, so the concern is basically, that Bob misses the deadline, then
>> Alice feels obligated to reclaim the funds.
>> In your proposal, the tx competition is between the secret-revealing
>> success TX and the non-secret-revealing revoke tx.
>> Whereas in my counterproposal, under the same conditions, the tx
>> competition is between the secret-revealing success tx and the
>> secret-revealing backout tx, and both transactions becoming visible on P2P
>> network means potentially both Alice and Bob know all the secrets on the
>> LTC side and end up competing over it, RBFing each other until the entire
>> fund goes to miners.
>>
>>
>> > >Without the refund#1 in your proposal, Bob refusing cooperation after
>> Alice puts the BTC into lock for 3 days and 2 further onchain transactions
>> >
>> > I'm not sure if I correctly understood what you're saying, but it's as
>> follows:
>> >
>> > Refund #1 can only safely be used before the signed success tx is given
>> to Bob. The cost to Alice at this point if Bob aborts is two on-chain
>> transactions while Bob hasn't put anything on-chain yet.
>> >
>> > Refund #2 needs to be used after Bob receives the signed success tx.
>> The cost to Alice is now three transactions, but Bob also went-on-chain by
>> this point, so causing this wasn't costless to Bob and is thus a similar
>> failure mode.
>>
>> I think it is not accurate that Bob is already on-chain before Alice can
>> be forced to use 3 transactions to fail.
>>
>> The revoke tx signatures are shared at step 0 of your protocol
>> description.
>> Thus Bob has a copy of the revoke tx that is valid once Alice signs and
>> confirms the funding transaction.
>> Bob can thus give a copy of the revoke tx with signature directly to its
>> favorite miner, forcing Alice to take 3 transactions to back out of the
>> swap.
>>
>> Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There
>> ain't no such thing as a global mempool"), Alice will only know about this
>> event when the revoke tx is confirmed once, at which point it is very
>> difficult to reverse, even if Alice has a refund#1 tx prepared.
>>
>> Bob can do this before step 2 in your protocol description, meaning
>> before Bob locks up any funds, so Bob can do this for free, and will even
>> use funds going back to Alice to pay for confirmation of the revoke tx.
>> Because Bob can do this for free, there is no disincentive for trolling
>> Bobs to exist whose sole life goal is to just grief possible Alices.
>>
>> This can be slightly mitigated by adding two CPFP outputs (one for each
>> participant) and using the minimum relayable feerate for the revoke tx so
>> that Bob is forced to bring its own fees in order to incentivize miners.
>> This is similar to the "bring your own fees" currently proposed for
>> Lightning, but note the recent hand-wringing about the various problems
>> this adds to mempools and CPFP and RBF rules and etc etc:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html
>>
>> We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a
>> bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the
>> transaction graph as special.
>> And forcing bring-your-own-fees means neither Alice nor Bob can swap all
>> their funds in a single operation, they have to keep a reserve.
>>
>>
>> Bob cannot safely perform step 2 before getting both signatures for the
>> revoke tx, as without Bob having access to the rveoke tx, if Bob locks up
>> LTC, Alice can stop responding and lock both their funds indefinitely with
>> Bob not having any way to recover its funds, which a rich Alice can use to
>> completely lock out an impoverished Bob.
>> But if Bob is given both signatures for the revoke tx before step 2, then
>> Bob can send the revoke tx to its favorite miner, forcing Alice to take 3
>> transactions to back out, before Bob locks any funds in LTC side.
>>
>> >
>> > I also agree with your observation that alternatively Bob can just
>> spend before the timelock expires.
>>
>> This seems to be the safest alternative; in my context, where Bob is a
>> CoinSwap server/maker, Bob can wait a short while for new clients/takers,
>> and if no new clients arrive, spend.
>> Bob can run multiple servers, each of which are given the completed
>> success transaction, and the servers can check that if the timeout is near,
>> to spam the Bitcoin P2P network with the completed success transactions.
>> (these servers need not even run fullnodes, they could just periodically
>> poll a number of blockchain explorers and electrum servers, and when the
>> blockheight approaches, attempt broadcast; if the "main" server that
>> accepts clients/takers has already spent the TXO the broadcast of the
>> completed success tx is simply rejected by the Bitcoin P2P network; if the
>> timeout is based on sidereal time then the backup servers only need to be
>> running NTP)
>>
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>

--000000000000e1fb3005a5849f07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div>&gt;potentially=
 both Alice and Bob know all the secrets on the LTC side and end up competi=
ng over it</div><div><br></div><div>That&#39;s exactly right.</div><div><br=
></div><div>&gt;Bob can thus give a copy of the revoke tx with signature di=
rectly to its favorite miner, forcing Alice to take 3 transactions</div><di=
v><br></div><div>Note that the timelock on the revoke tx is longer than the=
 timelock on refund tx #1. The idea is that Alice aborts the protocol by pu=
blishing refund tx #1 if the protocol hasn&#39;t reached step 4 in the svg =
by the time it becomes valid. This should entirely mitigate the issue you&#=
39;re describing.</div><div><br></div><div>&gt;adding two CPFP outputs (one=
 for each participant)</div><div><br></div><div> There seems to be a situat=
ion where RBF can be disabled by the other party, but I&#39;m not sure I se=
e it... Why would a single output spendable by either key be insufficient?

</div><div><br></div><div>&gt;We could use `SIGHASH_SINGLE | SIGHASH_ANYONE=
CANPAY` as well</div><div><br></div><div>Allowing others to add inputs/outp=
uts would introduce malleability. Refund tx #2 and the timeout tx would bec=
ome invalid.</div><div><br></div><div>&gt;Bob cannot safely perform step 2 =
before getting both signatures for the revoke tx</div><div><br></div><div>T=
hat&#39;s right, as you guessed, he does receive a copy of the signed revok=
e tx at protocol start.</div><div><br></div><div>&gt;&gt;<span style=3D"col=
or:rgb(80,0,80)">alternatively Bob can just spend before the timelock expir=
es.</span></div><div>&gt;This seems to be the safest alternative</div><div>=
<br></div><div>I agree not giving Alice time to publish the revoke tx is sa=
fest, but one does not preclude the other. The revoke tx is on an absolute =
timelock, so spending it before that time means you don&#39;t have anything=
 to worry=C2=A0about, and spending it later means you&#39;ll have to be onl=
ine and keep an eye out. If staying online is not a problem, then fee wise =
that seems preferable. As long as less than half of all valid (i.e. the tim=
elock was reached)=C2=A0revoke transactions get broadcast, you&#39;ll be sa=
ving on fees.</div><div><br></div><div>Cheers,</div><div>Ruben</div></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed,=
 May 13, 2020 at 11:57 AM Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gmail.=
com">rsomsen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr">Hi Chris,<div><br></div><div>Thanks =
for taking a look :)<br><div><br></div><div>&gt;it also improves privacy be=
cause the coins could stay unspend for a long time, potentially indefinitel=
y<br></div><div><br></div><div>Excellent point. The pre-swap setup transact=
ions would still be subject to timing/amount analysis, but it&#39;s clearly=
 a lot less problematic than the traditional 4 tx swap. And Payswap may be =
able to mitigate the amount analysis.</div><div><br></div><div>&gt;Using re=
lative timelocks and private key handover for old-style coinswaps would giv=
e us the same two-transaction effect</div></div><div><br></div><div>I agree=
, Lloyd pointed out the same thing. One thing to add is that such a setup w=
ould result in four on-chain transactions if the protocol is aborted, due t=
o the need to invalidate the refund transaction.</div><div><br></div><div>&=
gt;the idea of private key handover was mentioned as early as 2016 in the o=
riginal Lightning Network paper</div><div><br></div><div>Interesting! Thank=
s for pointing that out.</div><div><br></div><div>Cheers,</div><div>Ruben</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Wed, May 13, 2020 at 10:39 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPx=
j@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<=
br></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">Good morning Rub=
en,<br>
<br>
&gt; &gt;If the shortened refund transaction exists (labeled &quot;refund t=
ransaction #1&quot; in the SVG) then the same issue still occurs=C2=A0<br>
&gt;<br>
&gt; Yes, but there is one crucial difference: at that point in the protoco=
l (Bob has the success transaction and then stops cooperating) Alice and Bo=
b both had the opportunity not to take that path. Bob could have sent the s=
uccess transaction, and Alice could have waited and sent the revoke transac=
tion. They would essentially be &quot;colluding&quot; to fail.<br>
<br>
Okay, so the concern is basically, that Bob misses the deadline, then Alice=
 feels obligated to reclaim the funds.<br>
In your proposal, the tx competition is between the secret-revealing succes=
s TX and the non-secret-revealing revoke tx.<br>
Whereas in my counterproposal, under the same conditions, the tx competitio=
n is between the secret-revealing success tx and the secret-revealing backo=
ut tx, and both transactions becoming visible on P2P network means potentia=
lly both Alice and Bob know all the secrets on the LTC side and end up comp=
eting over it, RBFing each other until the entire fund goes to miners.<br>
<br>
<br>
&gt; &gt;Without the refund#1 in your proposal, Bob refusing cooperation af=
ter Alice puts the BTC into lock for 3 days and 2 further onchain transacti=
ons<br>
&gt;<br>
&gt; I&#39;m not sure if I correctly understood what you&#39;re saying, but=
 it&#39;s as follows:<br>
&gt;<br>
&gt; Refund #1 can only safely be used before the signed success tx is give=
n to Bob. The cost to Alice at this point if Bob aborts is two on-chain tra=
nsactions while Bob hasn&#39;t put anything on-chain yet.<br>
&gt;<br>
&gt; Refund #2 needs to be used after Bob receives the signed success tx. T=
he cost to Alice is now three transactions, but Bob also went-on-chain by t=
his point, so causing this wasn&#39;t costless to Bob and is thus a similar=
 failure mode.<br>
<br>
I think it is not accurate that Bob is already on-chain before Alice can be=
 forced to use 3 transactions to fail.<br>
<br>
The revoke tx signatures are shared at step 0 of your protocol description.=
<br>
Thus Bob has a copy of the revoke tx that is valid once Alice signs and con=
firms the funding transaction.<br>
Bob can thus give a copy of the revoke tx with signature directly to its fa=
vorite miner, forcing Alice to take 3 transactions to back out of the swap.=
<br>
<br>
Since Bob gave the tx directly to its favorite miner (TANSTAAGM: &quot;Ther=
e ain&#39;t no such thing as a global mempool&quot;), Alice will only know =
about this event when the revoke tx is confirmed once, at which point it is=
 very difficult to reverse, even if Alice has a refund#1 tx prepared.<br>
<br>
Bob can do this before step 2 in your protocol description, meaning before =
Bob locks up any funds, so Bob can do this for free, and will even use fund=
s going back to Alice to pay for confirmation of the revoke tx.<br>
Because Bob can do this for free, there is no disincentive for trolling Bob=
s to exist whose sole life goal is to just grief possible Alices.<br>
<br>
This can be slightly mitigated by adding two CPFP outputs (one for each par=
ticipant) and using the minimum relayable feerate for the revoke tx so that=
 Bob is forced to bring its own fees in order to incentivize miners.<br>
This is similar to the &quot;bring your own fees&quot; currently proposed f=
or Lightning, but note the recent hand-wringing about the various problems =
this adds to mempools and CPFP and RBF rules and etc etc: <a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2020-April/017757.html</a><br>
<br>
We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a bring-yo=
ur-own-fees, but that is not `SIGHASH_ALL` and thus marks the transaction g=
raph as special.<br>
And forcing bring-your-own-fees means neither Alice nor Bob can swap all th=
eir funds in a single operation, they have to keep a reserve.<br>
<br>
<br>
Bob cannot safely perform step 2 before getting both signatures for the rev=
oke tx, as without Bob having access to the rveoke tx, if Bob locks up LTC,=
 Alice can stop responding and lock both their funds indefinitely with Bob =
not having any way to recover its funds, which a rich Alice can use to comp=
letely lock out an impoverished Bob.<br>
But if Bob is given both signatures for the revoke tx before step 2, then B=
ob can send the revoke tx to its favorite miner, forcing Alice to take 3 tr=
ansactions to back out, before Bob locks any funds in LTC side.<br>
<br>
&gt;<br>
&gt; I also agree with your observation that alternatively Bob can just spe=
nd before the timelock expires.<br>
<br>
This seems to be the safest alternative; in my context, where Bob is a Coin=
Swap server/maker, Bob can wait a short while for new clients/takers, and i=
f no new clients arrive, spend.<br>
Bob can run multiple servers, each of which are given the completed success=
 transaction, and the servers can check that if the timeout is near, to spa=
m the Bitcoin P2P network with the completed success transactions.<br>
(these servers need not even run fullnodes, they could just periodically po=
ll a number of blockchain explorers and electrum servers, and when the bloc=
kheight approaches, attempt broadcast; if the &quot;main&quot; server that =
accepts clients/takers has already spent the TXO the broadcast of the compl=
eted success tx is simply rejected by the Bitcoin P2P network; if the timeo=
ut is based on sidereal time then the backup servers only need to be runnin=
g NTP)<br>
<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
</blockquote></div>

--000000000000e1fb3005a5849f07--