New Silent Payment version
3 messages, 17 to 22 Aug 2022. Started by woltx.
woltx (2), Ali Sherief
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
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@willtech•com•au> wrote:
Quoted text (44 lines)
> 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@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Besides, all silent payments are mined at the end of the day, so they are still transactions that are included in publicly auditable blocks.
The only thing that changes from the user's point of view is that these addresses cannot be heirarchically derived with BIP44 (or any other path for that matter). Nobody else can find out the HD paths of an address anyway.
- Ali
On Sun, 21 Aug 2022 22:01:34 +0000, woltx@protonmail•com wrote:
Quoted text (53 lines)
> 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@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