From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C7784C002D for ; Sat, 6 Aug 2022 14:11:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8C9684177B for ; Sat, 6 Aug 2022 14:11:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C9684177B Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=qQGaZ3IT X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 A3wdrdNroKgj for ; Sat, 6 Aug 2022 14:11:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 92CF841772 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp4.osuosl.org (Postfix) with ESMTPS id 92CF841772 for ; Sat, 6 Aug 2022 14:11:45 +0000 (UTC) Date: Sat, 06 Aug 2022 14:11:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1659795102; x=1660054302; bh=3Jp8Ga8Scijskj2MSg5Ob2NQ6HXTv5RYDy8ABf3LVTY=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=qQGaZ3ITu5siWu7mygVtDMCofm/wnpsv0B/348an8oj3t+sJQRjBgmK5TUoqajtCg yYMwXKSqvQAPLQidrExuYg5RRwRpMtSKRY8kOa4rtM+e953HcuBE6GILClTE/LbEPB QnPhhT5IhoWpZJ9XtuuYUTiIKSkcQwDl1AH+2XYk+Lu4pr40HgyijO/XOepgZo7+8t VIBedqIH1+N16+JKCtcrq6EhumgV3NBrDe/3rY/JGM1wnF2laGcPFDSWqyfomBnoZp jBbx44j9nwzTQ3WccQs5kRiLyoP+hWIRwbOUsMzNrl3izWiwvjSo4oGgPuuwRJN2mV r8GAnb7j6s2dw== To: Michael Folkson From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: <0wIl0PIW3Ah3Dg2_oRxpyQx6hJdGm9DbtSMJtePJ--_sKql5u17M4nxQmYfxqT_r1ztlvU5jH2jdpA15STtwFAsdkFnKRgpxuHDa9rqtcig=@protonmail.com> References: <0wIl0PIW3Ah3Dg2_oRxpyQx6hJdGm9DbtSMJtePJ--_sKql5u17M4nxQmYfxqT_r1ztlvU5jH2jdpA15STtwFAsdkFnKRgpxuHDa9rqtcig=@protonmail.com> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 08 Aug 2022 12:17:12 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] P2P trading replacement transactions 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: Sat, 06 Aug 2022 14:11:47 -0000 Hi Michael, > What do you mean by "replacement transaction"? Replacing or swapping outp= uts with a counterparty's? User broadcasts tx1 which is in mempool, wants to replace transaction with = higher fee rate however changes outputs and they are replaced with counterp= arty's outputs in tx2. > I guess I'm struggling to understand exactly what you are attempting to a= chieve here with regards to privacy and if this additional protocol complex= ity is worth it. Recall a 2 (or n) party coinjoin would get you an output w= here it isn't clear to blockchain observers which output you control and a = coinswap [0] would have you taking the coin history of your counterparty. W= hat does this scheme offer with regards to privacy that those don't? This s= eems to have more complexity too though I maybe misunderstanding something. Coinjoin and Coinswap offer different levels of privacy. This method just a= ims to break the assumption that tx2 (replacement transaction) is done to u= se a higher fee rate with same sender and recipient. It looks complex in th= e way I wrote in the last email or maybe because of implementation details = although UX will be simple and something like this: - user sends bitcoin in tx1 which is unconfirmed - tries to bump fee - wallet offer an extra privacy option - if user selects it, everything happens in the background and user just ne= eds to approve in between - user broadcasts tx2 to replace tx1 which has outputs shared by counterpar= ty - counterparty does the same for this user If this method makes sense or we have a similar market to trade replacement= s in future, it could be helpful in creating a process in which a chain of = replacements happen before bitcoin reaches the destination similar to tor c= ircuit. Example: - tx1 enters a pool - gets replaced by tx2 (different outputs) - tx3 replaces tx2 (different outputs) We could look at the logs and see tx3 originated at tx1 but no clue if orig= inal recipient received it in the end. There would be normal replacements d= one by other users so it would make analysis difficult. /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Saturday, August 6th, 2022 at 6:25 PM, Michael Folkson wrote: > Hi alicexbt > > What do you mean by "replacement transaction"? Replacing or swapping outp= uts with a counterparty's? > > I guess I'm struggling to understand exactly what you are attempting to a= chieve here with regards to privacy and if this additional protocol complex= ity is worth it. Recall a 2 (or n) party coinjoin would get you an output w= here it isn't clear to blockchain observers which output you control and a = coinswap [0] would have you taking the coin history of your counterparty. W= hat does this scheme offer with regards to privacy that those don't? This s= eems to have more complexity too though I maybe misunderstanding something. > > Thanks > Michael > > [0]:=C2=A0https://bitcoinops.org/en/topics/coinswap/ > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > > ------- Original Message ------- > On Friday, August 5th, 2022 at 15:44, alicexbt via bitcoin-dev wrote: > > > > Hi Bitcoin Developers, > > > > > > Does it make sense to trade replacement transactions for privacy? I hav= e shared basic details to implement this and would love to read opinions ab= out it or ways to improve it: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > alice=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > tx1: input a (0.01) -> output b1 (0.008) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> change c1 (0.001) > > > > tx2: input a (0.01) -> output e2 (0.007) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> output f2 (0.001) > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > bob > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > tx1: input d (0.011) -> output e1 (0.007) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> change f1 (0.003) > > > > tx2: input d (0.011) -> output b2 (0.008) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> output c2 (0.001) > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > carol > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > - creates an API to manage trades that will use 2 of 3 multisig > > - alice and bob create orders for replacement > > - either they could be matched automatically using some algorithm or bo= b manually accepts the offer > > - 2 of 3 multisig is created with Alice, Bob and Carol keys > > - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice > > - alice signs tx2 and shares tx with bob > > - alice locks 0.011 BTC in it and shares outputs b2,c2 with bob > > - bob signs tx2 and shares with alice > > - both replacement txs can be broadcasted > > - funds are released from 2 of 3 multisig with a tx having 3 outputs (o= ne to pay fee which goes to carol) > > > > > > > > positives: > > > > - privacy > > > > negatives: > > > > - extra fees > > - will take some time although everything will be managed by wallet wit= h API provided by carol > > - need to lock bitcoin with same amount as used in tx1 > > - amounts could still be used to link txs in some cases > > - carol and other peer knows the details > > > > > > > > > > /dev/fd0 > > > > > > > > > > Sent with Proton Mail secure email.