Date: Sun, 23 Oct 2022 07:00:07 +0000
To: alicexbt <alicexbt@protonmail.com>
From: woltx <woltx@protonmail.com>
Message-ID: <c4zJHH8C3dXNRFYDNKZShbmUcHYEl2A0bj8ByqgFxjb4pTOoKOi2_crU7YgZGhbmiCBPb_zrI3uZ0P4eNbpIJ43B-nPg0raxV-nsbl3x8rc=@protonmail.com>
In-Reply-To: <XxDzawKpNd-w31EPhjsQhW2VIjUOOAixK2X9RvZAB-Z-uFnasDCyLc5GlJ1HptXsuIggz7ee4tKMSxRsqMj8eoZUPgKuRFNqlejjObn43-4=@protonmail.com>
References: <P_21MLHGJicZ-hkbC4DGu86c5BtNKiH8spY4TOw5FJsfimdi_6VyHzU_y-s1mZsOcC2FA3EW_6w6W5qfV9dRK_7AvTAxDlwVfU-yhWZPEuo=@protonmail.com>
 <XxDzawKpNd-w31EPhjsQhW2VIjUOOAixK2X9RvZAB-Z-uFnasDCyLc5GlJ1HptXsuIggz7ee4tKMSxRsqMj8eoZUPgKuRFNqlejjObn43-4=@protonmail.com>
Feedback-ID: 48616983:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Silent Payment v4 (coinjoin support added)
Precedence: list

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 wo=
uld benefit coinjoin.

Using all inputs, it becomes possible to use SP addresses in coinjoins as l=
ong as all participants agree.
More information:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#varian=
t-using-all-inputs

2) Not sure about the concerns expressed by Andrew Poelstra in the pull req=
uest 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=C3=A8le Oul=C3=A8s in https://github.com/=
bitcoin/bitcoin/pull/24897#issuecomment-1276160738 and the reason was a dis=
cussion in PR about users thinking that each address would come from a diff=
erent 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,
>=20
> Thanks for working on silent payments improving it in each version.
>=20
> 1) All inputs being used sounds good although I do not understand how it =
would benefit coinjoin.
> 2) New RPC command name is better.
>=20
> > I opened a new PR (#1143) to add a function to convert from x-only to c=
ompressed public key with even y.
>=20
>=20
> Not sure about the concerns expressed by Andrew Poelstra in the pull requ=
est related to rogue-key attacks.
>=20
> > Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073=
893210875
> > "warnings": "This address is not a new identity. It is a re-use of an e=
xisting identity with a different label."
>=20
>=20
> I could not understand the warning in the output for `getsilentaddress` R=
PC when used with a label.
>=20
> /dev/fd0
>=20
> Sent with Proton Mail secure email.
>=20
>=20
> ------- Original Message -------
> On Tuesday, October 11th, 2022 at 12:32 PM, woltx via bitcoin-dev bitcoin=
-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > Silent Payment v4 (coinjoin support added)
> > Changes:
> >=20
> > . Silent payments now use all inputs to create transactions. Previously=
, they only used the first input. This change increases privacy and makes s=
ilent payments compatible with coinjoin.
> >=20
> > . `getspaddress` RPC renamed to `getsilentaddress` for clarity
> >=20
> > . Added support for silent payment in PSBT via `walletcreatefundedpsbt`=
 RPC.
> >=20
> > . Added a new index scheme (which stores the sum of input public keys f=
or each transaction). The previous index `bitcoin/signet/indexes/silentpaym=
entindex` should be removed as it is no longer compatible with this new ver=
sion.
> >=20
> > For reviewers:
> >=20
> > Now, silent payments use the scheme `hash(i1*X + i2*X + i3*X + ...)*G +=
 X =3D=3D hash(x*(I1+I2+I3+...))*G + X`, as described here: https://gist.gi=
thub.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inp=
uts
> >=20
> > 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 p=
refix byte).
> >=20
> > I opened a new PR (#1143) to add a function to convert from x-only to c=
ompressed public key with even y. This is the solution being used by the cu=
rrent silent payment implementation.
> >=20
> > Tutorial updated: https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073=
893210875