From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E5074C002D for ; Sat, 10 Sep 2022 10:17:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AD8D140157 for ; Sat, 10 Sep 2022 10:17:51 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AD8D140157 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=EI603YJs 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vQqJ9_3sZw3 for ; Sat, 10 Sep 2022 10:17:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EBE914012E Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp2.osuosl.org (Postfix) with ESMTPS id EBE914012E for ; Sat, 10 Sep 2022 10:17:49 +0000 (UTC) Date: Sat, 10 Sep 2022 10:17:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1662805066; x=1663064266; bh=254NNZ/dGZLMajTf1oz+/1NKwCp0WoIceOA1sBecjT8=; 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=EI603YJss4crEkDofBgXS15JsloKlMz3I2qCQdZ4xnIomvSTLoL0mloLv3fm6So01 oEMIT4wat8SJ5VlemdYyDMiOK6KtgQaTPdX8zZ5mJ/HYqDJc1JQVoTtIdn/Z0uEzKp SU8A4WaK1ac6XXVdrl6sU9d44seJJ9qszX+fmaAH2WRi6DUDLqFdLUKlZsPfBVaTuP c8Jr3szBwaUTz0Sx6daY5hnowahFUkbM5NpGscDCzYKcJHSXpEUuvJF1d/SKL09qOn Mv9K+0uBiSYenY8C0IB5UqqLWPXLFApGrOpbD4CXf6xnb0phP97iq57OnYFEa8NZ4Q UTmT5otWpggcw== To: woltx From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: References: 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: Sat, 10 Sep 2022 15:31:15 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr 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, 10 Sep 2022 10:17:52 -0000 Hi woltx, > I've been reviewing joinstr, and if I understand the code correctly, the = cryptographic scheme mentioned as an alternative to blind signatures isn't = implemented yet, is it? Currently, it seems that anyone can submit unrelate= d inputs and outputs. Thanks for reviewing joinstr. Yes, its not implemented right now as it requ= ires a NIP and at least one relay using it. > Instead of clients sending descriptors to the relay and then verifying th= em using `scantxoutset`, it can send `txid:out` with a message signed with = the address, verify using `verifymessage` and then use `gettxout` to retrie= ve the value. That way, only the owner can send the UTXO. `scantxoutset` is only used to get UTXO details (txid, vout and amount) as = I thought its easier for users to just share a descriptor for coinjoin.=20 If a user sends `txid:out` with a message signed with the address, this wou= ld be publicly available to everyone connected to same relay and links an i= nput with output. Responding with a secret shared by relay for the round co= nfirms user owns one of the input but does not reveal exact input. /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Friday, September 9th, 2022 at 9:05 PM, woltx wro= te: > Hi /dev/fd0, >=20 > I've been reviewing joinstr, and if I understand the code correctly, the = cryptographic scheme mentioned as an alternative to blind signatures isn't = implemented yet, is it? Currently, it seems that anyone can submit unrelate= d inputs and outputs. >=20 > Perhaps PR #24058 (https://github.com/bitcoin/bitcoin/pull/24058) (basic = support BIP-322) can improve this scheme as it implements proof of ownershi= p. >=20 > Instead of clients sending descriptors to the relay and then verifying th= em using `scantxoutset`, it can send `txid:out` with a message signed with = the address, verify using `verifymessage` and then use `gettxout` to retrie= ve the value. That way, only the owner can send the UTXO. >=20 > I've done some tests connected to a node with BIP322 enabled: >=20 > # to send > input_txt: str =3D json.dumps(input) > result =3D core.signmessage(wallet, input['address'], input_txt) > input['signature'] =3D result['result'] > nostr_interface.publish_input(input) >=20 > # to receive > def validate_input(input: dict[str, int, str, str]) -> bool: >=20 > # ... > result =3D core.verifymessage(address=3Dinput['address'], message=3Djson.= dumps(message), signature=3Dinput['signature']) > return result['error'] =3D=3D None and result['result'] =3D=3D True >=20 >=20 >=20 >=20 >=20 > ------- Original Message ------- > On Saturday, August 20th, 2022 at 1:52 PM, alicexbt via bitcoin-dev bitco= in-dev@lists.linuxfoundation.org wrote: >=20 >=20 >=20 > > Hi Max, > >=20 > > There a few DoS vectors that need to be fixed. Its just a proof of conc= ept that I wanted to share with everyone to get feedback which could be imp= roved over time. There is also a warning at the bottom of README to not use= this on mainnet as it might have bugs. > >=20 > > I will continue the development with coinjoin transactions on signet fo= r a few weeks until there is a stable release with no bugs. > >=20 > > I have a few ideas in mind for various relay types that might be used c= oncurrently to prevent numerous problems. Custom relays are supported by No= str. Examples include paying a fee to register for a round, subscribing wit= h a time limit, or using invite-only relays. I will run a free and open nos= tr relay for this project and try to fix the Dos issues before a mainnet ve= rsion is released for python script(for nerds) and android app (for all use= rs). > >=20 > > Related links: > >=20 > > https://github.com/fiatjaf/relayer > > https://github.com/fiatjaf/expensive-relay > > https://github.com/fiatjaf/relayer/tree/master/whitelisted > >=20 > > /dev/fd0 > >=20 > > Sent with Proton Mail secure email. > >=20 > > ------- Original Message ------- > > On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand max@towardsl= iberty.com wrote: > >=20 > > > Great to see an implementation of the idea. > > >=20 > > > Maybe I misunderstand, but isn't there a vulnerability of denial of s= ervice here? > > >=20 > > > A user who registers one input will receive the round secret identifi= er, and this is all the information required for output registration. Howev= er, that malicious user can now register multiple outputs, providing the sa= me secret, and nobody can link the malicious outputs to any specific input.= Therefor there cannot be a blame round where the malicious input is remove= d, and thus there can be a ongoing free denial of service attack without at= tribution or defense. > > >=20 > > > Skol > > > Max > > >=20 > > > On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev bi= tcoin-dev@lists.linuxfoundation.org wrote: > > >=20 > > > > Hi Bitcoin Developers, > > > >=20 > > > > I have written a python script as proof of concept for the coinjoin= implementation using nostr. I used a lot of Python scripts created by othe= rs in school, so it feels nice to offer something that could be useful to o= thers. > > > >=20 > > > > The implementation uses Bitcoin Core wallet and RPCs: `listunspent`= , `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizeps= bt` and `sendrawtransaction`. It requires python-nostr library because nost= r is used for coordination between peers. Nostr is a decentralized network = based on cryptographic keypairs. It is not peer-to-peer however simple and = scalable. > > > >=20 > > > > Every step is published as an event using a nostr relay and 5 peers= coordinate to create, sign and broadcast a coinjoin transaction. I need to= write a NIP that would be an alternative to blind signatures. Relay will s= hare a random secret with clients for one round which should be present in = output registration request although never gets published. If someone tries= to register an output without registering any inputs, request would not ha= ve the number initially shared with inputs so request would get rejected or= published as unverified. Relay would not be able to link inputs and output= s as the number is same for all inputs in a round and they get registered a= t different times with new keys and IP address. Clients can use multiple re= lays at the same time to avoid trusting one relay. This would result in dif= ferent shared secret number but same process. If a relay tries to cheat, us= ers will not sign the transaction and avoid using it in future. > > > >=20 > > > > Usage: > > > >=20 > > > > 1)Run `python coinjoin.py` and enter descriptor for one of the inpu= ts. > > > > 2)Script will check inputs for this round in every 30 seconds and r= egister a new adddress for output once 5 inputs are registered. > > > > 3)Similar check happens every 30 seconds for outputs. Last peer sho= uld create a PSBT. > > > > 4)Unsigned PSBT will be printed and signed by wallet with `walletpr= ocesspsbt` RPC. > > > > 5)Script will check signed PSBTs and last peer to sign should final= ize coinjoin transaction once 5 signed PSBTs are received. > > > > 6)Coinjoin transaction will be broadcasted and txid will printed. > > > >=20 > > > > Example: > > > >=20 > > > > ``` > > > > List of utxos in wallet: > > > >=20 > > > > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f= 21e99d13cd710cf2c1f21153c808)#x2hyyeg5 > > > >=20 > > > > Enter descriptor for the input registration: wpkh([53830dca/84'/1'/= 0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#= x2hyyeg5 > > > >=20 > > > > event id: bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378= d7d56f0 > > > >=20 > > > > tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output > > > >=20 > > > > event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fc= aaef041 > > > >=20 > > > > Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzO= rRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA///= //zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG= 9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+G= NSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc= 0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAA= AABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOg= AAAAAAAAAAAAAAAAAAAA=3D=3D > > > >=20 > > > > event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f= 6de4eba > > > >=20 > > > > Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrR= RS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////= zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9r= Ytv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNS= M3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/= FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAA= BYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAA= AAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wE= AAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XO= Sh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC534= 8U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyoo= MnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+= 91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA > > > >=20 > > > > event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09= ee7a139 > > > >=20 > > > > Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705d= ce8cc3564b > > > >=20 > > > > event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400= be93190 > > > > ``` > > > >=20 > > > > There are lot of things that could be improved and a few suggestion= s are in the gist that described the idea. I would love read to any opinion= s about this experiment and will start working on creating an Android app f= or joinstr next week. > > > >=20 > > > > Credits: > > > >=20 > > > > - fiatjaf (Nostr) > > > > - Andrew Chow (PSBT) > > > > - Jeff Thibault (python-nostr) > > > > - Existing coinjoin implmentations > > > >=20 > > > > /dev/fd0 > > > >=20 > > > > Sent with Proton Mail secure email. > > > >=20 > > > > bitcoin-dev mailing list > > > > bitcoin-dev@lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >=20 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev