Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

[alicexbt]

Hi Max,

There a few DoS vectors that need to be fixed. Its just a proof of concept that I wanted to share with everyone to get feedback which could be improved over time. There is also a warning at the bottom of README to not use this on mainnet as it might have bugs.

I will continue the development with coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. 

I have a few ideas in mind for various relay types that might be used concurrently to prevent numerous problems. Custom relays are supported by Nostr. Examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. I will run a free and open nostr relay for this project and try to fix the Dos issues before a mainnet version is released for python script(for nerds) and android app (for all users).

Related links: 

https://github.com/fiatjaf/relayer
https://github.com/fiatjaf/expensive-relay
https://github.com/fiatjaf/relayer/tree/master/whitelisted

/dev/fd0


Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand <max@towardsliberty.com> wrote:


> Great to see an implementation of the idea.
> 
> Maybe I misunderstand, but isn't there a vulnerability of denial of service here?
> 
> A user who registers one input will receive the round secret identifier, and this is all the information required for output registration. However, that malicious user can now register multiple outputs, providing the same secret, and nobody can link the malicious outputs to any specific input. Therefor there cannot be a blame round where the malicious input is removed, and thus there can be a ongoing free denial of service attack without attribution or defense.
> 
> Skol
> Max
> 
> 
> On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > Hi Bitcoin Developers,
> > 
> > I have written a python script as proof of concept for the [coinjoin implementation][1] using [nostr][2]. I used a lot of Python scripts created by others in school, so it feels nice to offer something that could be useful to others.
> > 
> > The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library because nostr 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.
> > 
> > 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 share 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 have the number initially shared with inputs so request would get rejected or published as unverified. Relay would not be able to link inputs and outputs as the number is same for all inputs in a round and they get registered at different times with new keys and IP address. Clients can use multiple relays at the same time to avoid trusting one relay. This would result in different shared secret number but same process. If a relay tries to cheat, users will not sign the transaction and avoid using it in future.
> > 
> > Usage:
> > 
> >  1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
> >  2)Script will check inputs for this round in every 30 seconds and register a new adddress for output once 5 inputs are registered.
> >  3)Similar check happens every 30 seconds for outputs. Last peer should create a PSBT.
> >  4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` RPC.
> >  5)Script will check signed PSBTs and last peer to sign should finalize coinjoin transaction once 5 signed PSBTs are received.
> >  6)Coinjoin transaction will be broadcasted and txid will printed.
> > 
> > Example:
> > 
> > ```
> > List of utxos in wallet:
> > 
> > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > 
> > Enter descriptor for the input registration: wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > 
> > event id:  bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0
> > 
> > ```
> > ```
> > tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output
> > 
> > event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
> > ```
> > ```
> > Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAAAAAAAAAAAAAA==
> > 
> > event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
> > ```
> > ```
> > Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA
> > 
> > event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
> > ```
> > ```
> > Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b
> > 
> > event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
> > ```
> > 
> > There are lot of things that could be improved and a few suggestions are in the gist that described the [idea][3]. I would love read to any opinions about this experiment and will start working on creating an Android app for joinstr next week.
> > 
> > Credits:
> > 
> > - fiatjaf (Nostr)
> > - Andrew Chow (PSBT)
> > - Jeff Thibault (python-nostr)
> > - Existing coinjoin implmentations
> > 
> > [1]: https://github.com/1440000bytes/joinstr
> > [2]: https://github.com/nostr-protocol/nostr
> > [3]: https://gist.github.com/1440000bytes/1c305097b070c8374cc3b91f50314a45
> > 
> > /dev/fd0
> > 
> > Sent with Proton Mail secure email.
> > 
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

[woltx]

Hi /dev/fd0,

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 unrelated inputs and outputs.

Perhaps PR #24058 (https://github.com/bitcoin/bitcoin/pull/24058) (basic support BIP-322) can improve this scheme as it implements proof of ownership. 

Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, it can send `txid:out` with a message signed with the address, verify using `verifymessage` and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO.

I've done some tests connected to a node with BIP322 enabled:

# to send
input_txt: str = json.dumps(input)
result = core.signmessage(wallet, input['address'], input_txt)
input['signature'] = result['result']
nostr_interface.publish_input(input)

# to receive
def validate_input(input: dict[str, int, str, str]) -> bool:
    # ...
    result = core.verifymessage(address=input['address'], message=json.dumps(message), signature=input['signature'])
    return result['error'] == None and result['result'] == True





------- Original Message -------
On Saturday, August 20th, 2022 at 1:52 PM, alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Hi Max,
> 
> There a few DoS vectors that need to be fixed. Its just a proof of concept that I wanted to share with everyone to get feedback which could be improved over time. There is also a warning at the bottom of README to not use this on mainnet as it might have bugs.
> 
> I will continue the development with coinjoin transactions on signet for a few weeks until there is a stable release with no bugs.
> 
> I have a few ideas in mind for various relay types that might be used concurrently to prevent numerous problems. Custom relays are supported by Nostr. Examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. I will run a free and open nostr relay for this project and try to fix the Dos issues before a mainnet version is released for python script(for nerds) and android app (for all users).
> 
> Related links:
> 
> https://github.com/fiatjaf/relayer
> https://github.com/fiatjaf/expensive-relay
> https://github.com/fiatjaf/relayer/tree/master/whitelisted
> 
> /dev/fd0
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> ------- Original Message -------
> On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand max@towardsliberty.com wrote:
> 
> 
> 
> > Great to see an implementation of the idea.
> > 
> > Maybe I misunderstand, but isn't there a vulnerability of denial of service here?
> > 
> > A user who registers one input will receive the round secret identifier, and this is all the information required for output registration. However, that malicious user can now register multiple outputs, providing the same secret, and nobody can link the malicious outputs to any specific input. Therefor there cannot be a blame round where the malicious input is removed, and thus there can be a ongoing free denial of service attack without attribution or defense.
> > 
> > Skol
> > Max
> > 
> > On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > 
> > > Hi Bitcoin Developers,
> > > 
> > > 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 others in school, so it feels nice to offer something that could be useful to others.
> > > 
> > > The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library because nostr 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.
> > > 
> > > 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 share 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 have the number initially shared with inputs so request would get rejected or published as unverified. Relay would not be able to link inputs and outputs as the number is same for all inputs in a round and they get registered at different times with new keys and IP address. Clients can use multiple relays at the same time to avoid trusting one relay. This would result in different shared secret number but same process. If a relay tries to cheat, users will not sign the transaction and avoid using it in future.
> > > 
> > > Usage:
> > > 
> > > 1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
> > > 2)Script will check inputs for this round in every 30 seconds and register a new adddress for output once 5 inputs are registered.
> > > 3)Similar check happens every 30 seconds for outputs. Last peer should create a PSBT.
> > > 4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` RPC.
> > > 5)Script will check signed PSBTs and last peer to sign should finalize coinjoin transaction once 5 signed PSBTs are received.
> > > 6)Coinjoin transaction will be broadcasted and txid will printed.
> > > 
> > > Example:
> > > 
> > > ```
> > > List of utxos in wallet:
> > > 
> > > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > > 
> > > Enter descriptor for the input registration: wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > > 
> > > event id: bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0
> > > 
> > > 
> > > tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output
> > > 
> > > event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
> > > 
> > > Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAAAAAAAAAAAAAA==
> > > 
> > > event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
> > > 
> > > Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA
> > > 
> > > event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
> > > 
> > > Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b
> > > 
> > > event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
> > > ```
> > > 
> > > There are lot of things that could be improved and a few suggestions are in the gist that described the idea. I would love read to any opinions about this experiment and will start working on creating an Android app for joinstr next week.
> > > 
> > > Credits:
> > > 
> > > - fiatjaf (Nostr)
> > > - Andrew Chow (PSBT)
> > > - Jeff Thibault (python-nostr)
> > > - Existing coinjoin implmentations
> > > 
> > > /dev/fd0
> > > 
> > > Sent with Proton Mail secure email.
> > > 
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

[alicexbt]

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 unrelated inputs and outputs.

Thanks for reviewing joinstr. Yes, its not implemented right now as it requires a NIP and at least one relay using it.

> Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, it can send `txid:out` with a message signed with the address, verify using `verifymessage` and then use `gettxout` to retrieve 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. 

If a user sends `txid:out` with a message signed with the address, this would be publicly available to everyone connected to same relay and links an input with output. Responding with a secret shared by relay for the round confirms 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 <woltx@protonmail.com> wrote:


> Hi /dev/fd0,
> 
> 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 unrelated inputs and outputs.
> 
> Perhaps PR #24058 (https://github.com/bitcoin/bitcoin/pull/24058) (basic support BIP-322) can improve this scheme as it implements proof of ownership.
> 
> Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, it can send `txid:out` with a message signed with the address, verify using `verifymessage` and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO.
> 
> I've done some tests connected to a node with BIP322 enabled:
> 
> # to send
> input_txt: str = json.dumps(input)
> result = core.signmessage(wallet, input['address'], input_txt)
> input['signature'] = result['result']
> nostr_interface.publish_input(input)
> 
> # to receive
> def validate_input(input: dict[str, int, str, str]) -> bool:
> 
> # ...
> result = core.verifymessage(address=input['address'], message=json.dumps(message), signature=input['signature'])
> return result['error'] == None and result['result'] == True
> 
> 
> 
> 
> 
> ------- Original Message -------
> On Saturday, August 20th, 2022 at 1:52 PM, alicexbt via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> 
> 
> > Hi Max,
> > 
> > There a few DoS vectors that need to be fixed. Its just a proof of concept that I wanted to share with everyone to get feedback which could be improved over time. There is also a warning at the bottom of README to not use this on mainnet as it might have bugs.
> > 
> > I will continue the development with coinjoin transactions on signet for a few weeks until there is a stable release with no bugs.
> > 
> > I have a few ideas in mind for various relay types that might be used concurrently to prevent numerous problems. Custom relays are supported by Nostr. Examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. I will run a free and open nostr relay for this project and try to fix the Dos issues before a mainnet version is released for python script(for nerds) and android app (for all users).
> > 
> > Related links:
> > 
> > https://github.com/fiatjaf/relayer
> > https://github.com/fiatjaf/expensive-relay
> > https://github.com/fiatjaf/relayer/tree/master/whitelisted
> > 
> > /dev/fd0
> > 
> > Sent with Proton Mail secure email.
> > 
> > ------- Original Message -------
> > On Saturday, August 20th, 2022 at 10:04 AM, Max Hillebrand max@towardsliberty.com wrote:
> > 
> > > Great to see an implementation of the idea.
> > > 
> > > Maybe I misunderstand, but isn't there a vulnerability of denial of service here?
> > > 
> > > A user who registers one input will receive the round secret identifier, and this is all the information required for output registration. However, that malicious user can now register multiple outputs, providing the same secret, and nobody can link the malicious outputs to any specific input. Therefor there cannot be a blame round where the malicious input is removed, and thus there can be a ongoing free denial of service attack without attribution or defense.
> > > 
> > > Skol
> > > Max
> > > 
> > > On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > 
> > > > Hi Bitcoin Developers,
> > > > 
> > > > 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 others in school, so it feels nice to offer something that could be useful to others.
> > > > 
> > > > The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library because nostr 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.
> > > > 
> > > > 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 share 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 have the number initially shared with inputs so request would get rejected or published as unverified. Relay would not be able to link inputs and outputs as the number is same for all inputs in a round and they get registered at different times with new keys and IP address. Clients can use multiple relays at the same time to avoid trusting one relay. This would result in different shared secret number but same process. If a relay tries to cheat, users will not sign the transaction and avoid using it in future.
> > > > 
> > > > Usage:
> > > > 
> > > > 1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
> > > > 2)Script will check inputs for this round in every 30 seconds and register a new adddress for output once 5 inputs are registered.
> > > > 3)Similar check happens every 30 seconds for outputs. Last peer should create a PSBT.
> > > > 4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` RPC.
> > > > 5)Script will check signed PSBTs and last peer to sign should finalize coinjoin transaction once 5 signed PSBTs are received.
> > > > 6)Coinjoin transaction will be broadcasted and txid will printed.
> > > > 
> > > > Example:
> > > > 
> > > > ```
> > > > List of utxos in wallet:
> > > > 
> > > > wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > > > 
> > > > Enter descriptor for the input registration: wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5
> > > > 
> > > > event id: bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0
> > > > 
> > > > tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output
> > > > 
> > > > event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
> > > > 
> > > > Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAAAAAAAAAAAAAA==
> > > > 
> > > > event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
> > > > 
> > > > Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA
> > > > 
> > > > event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
> > > > 
> > > > Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b
> > > > 
> > > > event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
> > > > ```
> > > > 
> > > > There are lot of things that could be improved and a few suggestions are in the gist that described the idea. I would love read to any opinions about this experiment and will start working on creating an Android app for joinstr next week.
> > > > 
> > > > Credits:
> > > > 
> > > > - fiatjaf (Nostr)
> > > > - Andrew Chow (PSBT)
> > > > - Jeff Thibault (python-nostr)
> > > > - Existing coinjoin implmentations
> > > > 
> > > > /dev/fd0
> > > > 
> > > > Sent with Proton Mail secure email.
> > > > 
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] joinstr: coinjoin implementation using nostr

[alicexbt]

Hi Bitcoin Developers,

I have written a python script as proof of concept for the [coinjoin implementation][1] using [nostr][2]. I used a lot of Python scripts created by others in school, so it feels nice to offer something that could be useful to others.

The implementation uses Bitcoin Core wallet and RPCs: `listunspent`, `getnewaddress`, `scantxoutset`, `createpsbt`, `combinepsbt`, `finalizepsbt` and `sendrawtransaction`. It requires python-nostr library because nostr 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.

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 share 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 have the number initially shared with inputs so request would get rejected or published as unverified. Relay would not be able to link inputs and outputs as the number is same for all inputs in a round and they get registered at different times with new keys and IP address. Clients can use multiple relays at the same time to avoid trusting one relay. This would result in different shared secret number but same process. If a relay tries to cheat, users will not sign the transaction and avoid using it in future.

Usage:

 1)Run `python coinjoin.py` and enter descriptor for one of the inputs.
 2)Script will check inputs for this round in every 30 seconds and register a new adddress for output once 5 inputs are registered.
 3)Similar check happens every 30 seconds for outputs. Last peer should create a PSBT.
 4)Unsigned PSBT will be printed and signed by wallet with `walletprocesspsbt` RPC.
 5)Script will check signed PSBTs and last peer to sign should finalize coinjoin transaction once 5 signed PSBTs are received.
 6)Coinjoin transaction will be broadcasted and txid will printed.

Example:

```
List of utxos in wallet:

wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

Enter descriptor for the input registration: wpkh([53830dca/84'/1'/0'/0/0]02449be5fb74725255eeeb50eba930fa87705f21e99d13cd710cf2c1f21153c808)#x2hyyeg5

event id:  bcbbe62d75d99fed73f1e50ac58a38d1840b658951893e63c0322b378d7d56f0

```
```
tb1qhxrp4zl54ul0twtyz0gury5399q7z0kvqqrl6m registered for output

event id: 9449c9065bef356d21507a98f88b028b17fc1c49eb195c8d4420604fcaaef041
```
```
Unsigned PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAAAAAAAAAAAAAA==

event id: 976744b38fa9343fb79e1b5215512ead6ee08e5890d79a201fc5b872f6de4eba
```
```
Signed PSBT: cHNidP8BAP1yAQIAAAAFtMaoJYcXvOG5L3Yaz3YyS7gIt4h5/zzOrRRS3hrVvwoAAAAAAP////+o83geaSm4L76KToIUl5MiZqLAUbIDJLq6DWrjP/3b8AEAAAAA/////zEF3CXIvVHpIa7No1s1yg+KtyOfXTRSyWnOdXMfzcDwAQAAAAD/////wMa4XAgnU+39Ien+KG9rYtv8bLMNYakmZyY/QFfwLRcAAAAAAP/////5M42ID6uLmQTb2tnFHnN7UMpnDD25uN8ZX7A+GNSM3QEAAAAA/////wV4xwEAAAAAABYAFLmGGov0rz71uWQT0cGSkSlB4T7MeMcBAAAAAAAWABSc0/FM6Hdbdxh10IJkYOklVFWqjnjHAQAAAAAAFgAUPSZKe/w6PT6qIF+WhL4wHaFymjd4xwEAAAAAABYAFMx0rxYlpPWB3NFry4Ctk2eVi/UNeMcBAAAAAAAWABSzc4xK0VTfvjK0MHXrAUFLYgYnOgAAAAAAAQBxAgAAAAG+qpMXZCy6tBuUlgo8JD0GVXKp60FkhwDeg2sF1fkFkwMAAAAA/f///wLo9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUWwMAAAAAAAAWABRfPf//hwMjHB4OKj87cU19XOSh7yOWAQABAR/o9wEAAAAAABYAFFfLA5xarC/w/SxeMDQ5tuXrYJLUAQhrAkcwRAIgOIhLoC5348U8YkEr4GU1K4yWskIOEXgW4Wsk/W2cR7ICIEJXqtOuDJ5CkwrSuwJLWtzab4dslbN3KuL/pyooMnOCASECRJvl+3RyUlXu61DrqTD6h3BfIemdE81xDPLB8hFTyAgAAAAAACICA77Cnd6o3kr0yc+91eabpOn5igs/MUMbudNYSS6oyMWMGFODDcpUAACAAQAAgAAAAIAAAAAAFAAAAAAAAAAA

event id: 5846b6e6902f3c5a43496d7d9785ed62444aa74963f03c33d637d8b09ee7a139
```
```
Coinjoin tx: 75e490b10b15a6a0422f25ff66ad98ef70390c8fecaac02712705dce8cc3564b

event id: 9b5d4bf279b59e2b6e539e683fba83da72dce2b640360aa95db1b1400be93190
```

There are lot of things that could be improved and a few suggestions are in the gist that described the [idea][3]. I would love read to any opinions about this experiment and will start working on creating an Android app for joinstr next week.

Credits:

- fiatjaf (Nostr)
- Andrew Chow (PSBT)
- Jeff Thibault (python-nostr)
- Existing coinjoin implmentations

[1]: https://github.com/1440000bytes/joinstr
[2]: https://github.com/nostr-protocol/nostr
[3]: https://gist.github.com/1440000bytes/1c305097b070c8374cc3b91f50314a45

/dev/fd0

Sent with Proton Mail secure email.

Re: [bitcoin-dev] joinstr: coinjoin implementation using nostr

[Max Hillebrand]

[-- Attachment #1.1: Type: text/plain, Size: 612 bytes --]

Great to see an implementation of the idea.

Maybe I misunderstand, but isn't there a vulnerability of denial of service here?

A user who registers one input will receive the round secret identifier, and this is all the information required for output registration. However, that malicious user can now register multiple outputs, providing the same secret, and nobody can link the malicious outputs to any specific input. Therefor there cannot be a blame round where the malicious input is removed, and thus there can be a ongoing free denial of service attack without attribution or defense.

Skol
Max

[-- Attachment #1.2: Type: text/html, Size: 6716 bytes --]

[-- Attachment #2: sender_key.asc --]
[-- Type: application/pgp-keys, Size: 3910 bytes --]