woltx [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-05-24 to 2022-10-23
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:15:05

- reply

📅 Original date posted:2022-10-23
📝 Original message:Hi /dev/fd0
I haven't accessed ML for a while.
1) All inputs being used sounds good although I do not understand how it would benefit coinjoin.
Using all inputs, it becomes possible to use SP addresses in coinjoins as long as all participants agree.
More information:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
2) Not sure about the concerns expressed by Andrew Poelstra in the pull request related to rogue-key attacks.
I think Andrew Poelstra is referring to a multi-party scheme.
This is not the case with the Silent Payments scheme, which only relies on transaction data, which is publicly available on the blockchain.
3) I could not understand the warning in the output for `getsilentaddress` RPC when used with a label.
This warning was suggested by Aurèle Oulès in https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1276160738 and the reason was a discussion in PR about users thinking that each address would come from a different key and not the same key.
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, October 12th, 2022 at 6:04 AM, alicexbt <alicexbt at protonmail.com> wrote:
> Hi woltx,
>
> Thanks for working on silent payments improving it in each version.
>
> 1) All inputs being used sounds good although I do not understand how it would benefit coinjoin.
> 2) New RPC command name is better.
>
> > I opened a new PR (#1143) to add a function to convert from x-only to compressed public key with even y.
>
>
> Not sure about the concerns expressed by Andrew Poelstra in the pull request related to rogue-key attacks.
>
> > Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
> > "warnings": "This address is not a new identity. It is a re-use of an existing identity with a different label."
>
>
> I could not understand the warning in the output for `getsilentaddress` RPC when used with a label.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
>
> ------- Original Message -------
> On Tuesday, October 11th, 2022 at 12:32 PM, woltx via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > Silent Payment v4 (coinjoin support added)
> > Changes:
> >
> > . Silent payments now use all inputs to create transactions. Previously, they only used the first input. This change increases privacy and makes silent payments compatible with coinjoin.
> >
> > . `getspaddress` RPC renamed to `getsilentaddress` for clarity
> >
> > . Added support for silent payment in PSBT via `walletcreatefundedpsbt` RPC.
> >
> > . Added a new index scheme (which stores the sum of input public keys for each transaction). The previous index `bitcoin/signet/indexes/silentpaymentindex` should be removed as it is no longer compatible with this new version.
> >
> > For reviewers:
> >
> > Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X == hash(x*(I1+I2+I3+...))*G + X`, as described here: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
> >
> > As inputs can be Taproot, this introduced a new issue as `bitcoin-core/secp256k1` does not support x-only public key sum (perhaps due to missing prefix byte).
> >
> > I opened a new PR (#1143) to add a function to convert from x-only to compressed public key with even y. This is the solution being used by the current silent payment implementation.
> >
> > Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875

2023-06-07 23:15:04

- reply

📅 Original date posted:2022-10-11
📝 Original message:Silent Payment v4 (coinjoin support added)
Changes:
. Silent payments now use all inputs to create transactions. Previously, they only used the first input. This change increases privacy and makes silent payments compatible with coinjoin.
. `getspaddress` RPC renamed to `getsilentaddress` for clarity
. Added support for silent payment in PSBT via `walletcreatefundedpsbt` RPC.
. Added a new index scheme (which stores the sum of input public keys for each transaction). The previous index `bitcoin/signet/indexes/silentpaymentindex` should be removed as it is no longer compatible with this new version.
For reviewers:
Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G + X == hash(x*(I1+I2+I3+...))*G + X`, as described here: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
As inputs can be Taproot, this introduced a new issue as `bitcoin-core/secp256k1` does not support x-only public key sum (perhaps due to missing prefix byte).
I opened a new PR (#1143) to add a function to convert from x-only to compressed public key with even y. This is the solution being used by the current silent payment implementation.
Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/0d3b9f46/attachment.html>

2023-06-07 23:13:57

- reply

📅 Original date posted:2022-09-29
📝 Original message:This new version addresses most (or all) requests made in PR:
. Implements the new scheme suggested by Ruben Somsen that allows multiple silent addresses per wallet with minimal overhead.
. Implements a new RPC to retrieve silent addresses, which allows users to assign different labels to different addresses. That way, the user knows which silent address the UTXO came from.
Example:
./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
# This will return the same address as above (both have no label)
./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress
tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
# New label, new address
./src/bitcoin-cli -signet -rpcwallet="receiver" getspaddress 'donation'
tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
In this new scheme, the address has a new field called identifier, which tells the receiver and sender how to set the address correctly.
If the receiver, for whatever reason, doesn't know which identifiers have been used, there is no problem. The wallet can scan all identifiers from 0 to 99. Currently, only 100 different identifiers per wallet are allowed. This limit, however, can be increased at any time in the future.
Unlike address formats so far, sp addresses are not script-related and may eventually include any additional information needed, such as an expiration timestamp (or block height). That way, users don't have to track the address indefinitely.
As usual I wrote a step by step tutorial:
https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220929/bd368220/attachment.html>

2023-06-07 23:13:20

- reply

📅 Original date posted:2022-09-09
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:12:51

- reply

📅 Original date posted:2022-08-21
📝 Original message:The current Silent Payment implementation uses the standard Taproot script (Segwit V1).
This does not in any way affect the consensus or auditability rules.
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, August 17th, 2022 at 11:21 PM, <damian at willtech.com.au> wrote:
> Let's be clear, if Bitcoin allows secret payments that cannot be
> publicly audited then they have exceeded the original consensus that
> gave Bitcoin fungibility and I will be publicly disavowing Bitcoin and
> advocating for a full sell down. Why don't you resurrect Monero. -DA.
>
> On 2022-08-17 10:08, woltx via bitcoin-dev wrote:
>
> > PR #24897 (https://github.com/bitcoin/bitcoin/pull/24897) has been
> > updated with a new silent payment version, which eliminates some
> > manual steps from the previous version (such as the need to set the
> > `keypool` to avoid costly multi-key scan).
> >
> > This is achieved by using a new descriptor type ("sp()") that has no
> > range and contains exactly one key.
> >
> > Example: "sp(cQq73sG9....JD51uaRD)#9llg6xjm"
> >
> > This descriptor introduces a new type of output: "silent-payment".
> > This output type returns a standard Taproot script (Segwit V1), but
> > with HRP changed from "bc" to "sp" on the mainnet (or "tsp" on
> > testnet and signet).
> >
> > This output type will always generate the same address (unless another
> > "sp" descriptor is enabled on the same wallet).
> >
> > $ ./src/bitcoin-cli -signet getnewaddress '' 'silent-payment'
> > tsp1pfmjyl7ecpmx8yf8cu6g3ez36jy7s9mzuh5pdnal3k0n588uzgmfs4s4fws
> >
> > To create a silent transaction, simply use the silent payment address
> > as one of the outputs.
> >
> > The "send" RPC will automatically identify and tweak it.
> >
> > The transaction can contain multiple outputs, combining silent and
> > standard addresses.
> >
> > I have written a step by step signet tutorial so reviewers can test
> > this new version easily.
> >
> > https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:12:51

- reply

2023-06-07 23:12:50

- reply

📅 Original date posted:2022-08-16
📝 Original message:PR #24897 (https://github.com/bitcoin/bitcoin/pull/24897) has been updated with a new silent payment version, which eliminates some manual steps from the previous version (such as the need to set the `keypool` to avoid costly multi-key scan).
This is achieved by using a new descriptor type ("sp()") that has no range and contains exactly one key.
Example: "sp(cQq73sG9....JD51uaRD)#9llg6xjm"
This descriptor introduces a new type of output: "silent-payment". This output type returns a standard Taproot script (Segwit V1), but with HRP changed from "bc" to "sp" on the mainnet (or "tsp" on testnet and signet).
This output type will always generate the same address (unless another "sp" descriptor is enabled on the same wallet).
$ ./src/bitcoin-cli -signet getnewaddress '' 'silent-payment'
tsp1pfmjyl7ecpmx8yf8cu6g3ez36jy7s9mzuh5pdnal3k0n588uzgmfs4s4fws
To create a silent transaction, simply use the silent payment address as one of the outputs.
The "send" RPC will automatically identify and tweak it.
The transaction can contain multiple outputs, combining silent and standard addresses.
I have written a step by step signet tutorial so reviewers can test this new version easily.
https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220817/97c45a02/attachment.html>

2023-06-07 23:12:50

- reply

2023-06-07 23:09:59

- reply

📅 Original date posted:2022-05-23
📝 Original message:I created a short and simple tutorial on how to make silent payments on signet.
https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee
In this tutorial, the user will generate an address, publish it, receive and spend coins from it and still no transactions are shown from this address in a blockchain explorer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220524/45256620/attachment.html>