From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1082EC016F for ; Wed, 13 May 2020 11:39:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id EE34F88ABC for ; Wed, 13 May 2020 11:39:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwha3UHG5RnY for ; Wed, 13 May 2020 11:39:19 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by hemlock.osuosl.org (Postfix) with ESMTPS id 0A4C388B24 for ; Wed, 13 May 2020 11:39:19 +0000 (UTC) Date: Wed, 13 May 2020 11:39:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589369956; bh=A2OYMWZdLTSTacED7ebyvuwnoKjEQP9E3hWP9CWnZsk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=u0wB9sK7yjPAO0cAbPgoiPcElQFB1ZiS2G5m8zOo0mjA0uh+ipIvwH63GoCUQot5G rYcl+Heim8w++bt5rW4tuyd77FJgvZRMZ3Rs8lvEF15KvLmXQJPPDr6ave8qIHy1uZ HgBBhzdvBM0MxmlnAOcx8AX0PYe1zdoHWlqZQy1w= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 11:39:21 -0000 Good morning Ruben, > 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 re= fund 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 beco= mes valid. This should entirely mitigate the issue you're describing. But if refund tx #1 at all exists, then you drop to the same issue you obje= cted to with my proposal, which is that, on completion of the protocol, if = Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) the= n Alice can broadcast it, putting both their funds into chaos. So you might as well just use my counterproposal instead, which is simpler,= gets bring-your-own-fees for free, etc. I suppose there is some *slight* improvement in that with your proposal, Al= ice *can* use revoke tx -> refund tx #2, but still, if Alice is insane then= it could very well mess with the protocol by instead using refund tx #1. Thus, if Bob wants to survive in an environment where Alices are possibly i= nsane (e.g. the real world), it should do everything in its power to ensure= that the BTC txo is spent before the timeout of refund tx #1, if refund tx= #1 exists at all. And if Bob is already going to do that, then Alice and Bob might as well ju= st use my counterproposal etc etc. > >adding two CPFP outputs (one for each participant) > > There seems to be a situation where RBF can be disabled by the other part= y, but I'm not sure I see it... Why would a single output spendable by eith= er key be insufficient? If one party quickly broadcasts a long chain of low-feerate transactions on= top of the single output, then the output is "pinned". Low feerate means it is undesirable for miners to mine it, because it pays = low for the amount of blockspace it has. But because there is a long chain of transactions, the absolute fee of that= chain can be sizable, and we have a rule in RBF which, paraphrased, goes s= omething like "the replacing transaction should also have a higher absolute= fee than *all* the transactions it replaces", meaning the fee jump that th= e other side has to offer *has to be* pretty big. If the other outputs of the tx are then multisig, then the pinning particip= ant can simply refuse to sign for those, and if the existing txes spending = the other outputs are relative-time-locked, they cannot be used to CPFP the= revoke tx onchain. This is why we eventually decided in Lightning to use two CPFP outpoints ra= ther than one, and are also realizing just how much of a headache the RBF r= ules are, sigh. Still, in your proposed protocol the dependent transactions are all relativ= e-timelocked, so timely confirmation of the revoke tx is not necessary, unl= ike in the case of Lightning where all HTLCs have to use an absolute timelo= ck because we have to coordinate multiple HTLCs in forwarding and violation= of the timelocks can lead to headaches and fund loss and so on. So maybe a single hook output, or even none at all, is workable. > > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well > > Allowing others to add inputs/outputs would introduce malleability. Refun= d tx #2 and the timeout tx would become invalid. Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that. > >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=C2= =A0about, 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 prefe= rable. As long as less than half of all valid (i.e. the timelock was reache= d)=C2=A0revoke transactions get broadcast, you'll be saving on fees. In a world where Alice may be insane and mess with the protocol just to gri= ef Bob even if Alice loses its money (e.g. the real world), Bob should not = depend on Alice behaving correctly or politely, so it should still have bac= kup watchers set up in case it accidentally goes to sleep and so on. Regards, ZmnSCPxj