* [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