* [bitcoin-dev] Silent Payment v4 (coinjoin support added)
@ 2022-10-11 7:02 woltx
2022-10-12 9:04 ` alicexbt
0 siblings, 1 reply; 4+ messages in thread
From: woltx @ 2022-10-11 7:02 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1937 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Silent Payment v4 (coinjoin support added)
2022-10-11 7:02 [bitcoin-dev] Silent Payment v4 (coinjoin support added) woltx
@ 2022-10-12 9:04 ` alicexbt
2022-10-23 7:00 ` woltx
0 siblings, 1 reply; 4+ messages in thread
From: alicexbt @ 2022-10-12 9:04 UTC (permalink / raw)
To: woltx; +Cc: bitcoin-dev
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@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Silent Payment v4 (coinjoin support added)
2022-10-12 9:04 ` alicexbt
@ 2022-10-23 7:00 ` woltx
2022-10-23 20:54 ` alicexbt
0 siblings, 1 reply; 4+ messages in thread
From: woltx @ 2022-10-23 7:00 UTC (permalink / raw)
To: alicexbt; +Cc: bitcoin-dev
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@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@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Silent Payment v4 (coinjoin support added)
2022-10-23 7:00 ` woltx
@ 2022-10-23 20:54 ` alicexbt
0 siblings, 0 replies; 4+ messages in thread
From: alicexbt @ 2022-10-23 20:54 UTC (permalink / raw)
To: woltx; +Cc: bitcoin-dev
Hi woltx,
Thanks for the response.
> 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
Using new addresses and SP address would be same in my opinion in coinjoin.
> 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.
Sounds good.
> 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.
It makes sense although could be rephrased.
/dev/fd0
Sent with Proton Mail secure email.
------- Original Message -------
On Sunday, October 23rd, 2022 at 12:30 PM, woltx <woltx@protonmail•com> wrote:
> 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@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@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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-10-23 20:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-11 7:02 [bitcoin-dev] Silent Payment v4 (coinjoin support added) woltx
2022-10-12 9:04 ` alicexbt
2022-10-23 7:00 ` woltx
2022-10-23 20:54 ` alicexbt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox