* [bitcoin-dev] Third version of Silent Payment implementation
@ 2022-09-29 22:19 woltx
2022-09-29 23:03 ` Ruben Somsen
0 siblings, 1 reply; 3+ messages in thread
From: woltx @ 2022-09-29 22:19 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2421 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Third version of Silent Payment implementation
2022-09-29 22:19 [bitcoin-dev] Third version of Silent Payment implementation woltx
@ 2022-09-29 23:03 ` Ruben Somsen
2022-10-03 23:41 ` Ruben Somsen
0 siblings, 1 reply; 3+ messages in thread
From: Ruben Somsen @ 2022-09-29 23:03 UTC (permalink / raw)
To: woltx, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3851 bytes --]
Hi woltx,
Excellent work.
>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead
To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course), which
enables you to distinguish between different payment purposes (e.g. some
people donate to you for purpose A, others for purpose B). Here's my
original comment describing it:
"Naively, the issue is that two keys means twice the scanning, but an
interesting alternative would be to simply use the same key (assuming
you're OK with using the same identity) but add a public identifier f to it
when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
. This means every additional "address" only costs one additional ECC
addition when scanning (relatively cheap compared to doing ECC
multiplications).
The main downside with this is that f becomes crucial for recovering from
backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
remember how many "addresses" you issued (and perhaps overshoot when
unsure) to ensure recovery of funds, though of course you'd rather also
remember which index is associated with what payment reason.
Absolute worst case scenario you could even do something similar to the gap
limit where you scan the full history (not just the UTXO set so you don't
miss spent outputs) with a default max index of e.g. 100, and then if you
find out most of them are in use, you scan the next 100, etc. Costly, but
thorough, and only needed as a last resort."
Original comment here:
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
Also good to note that f needs to be communicated to the sender somehow,
perhaps as part of the address format.
Cheers,
Ruben
On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5598 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Third version of Silent Payment implementation
2022-09-29 23:03 ` Ruben Somsen
@ 2022-10-03 23:41 ` Ruben Somsen
0 siblings, 0 replies; 3+ messages in thread
From: Ruben Somsen @ 2022-10-03 23:41 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5307 bytes --]
Hi,
Apologies, the link I sent in my previous post was incorrect and should
have been:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521
Let me also use this opportunity to share another clarifying comment:
"There seems to be some confusion about the function of the identifier. Its
function is not to create more than one identity, but to be able to
distinguish why someone paid you. For example, when the same entity is
raising money on behalf of two different charities and wants to know for
which of the two charities the sender intended their donation.
To be absolutely clear, the payments that appear on-chain are still
absolutely unlinkable by a third party observer, nor are they able to tell
which identifier was used.
In cases where you don't want people to know that you're the same entity,
the identifier is insufficient – you'll need a completely separate Silent
Payment address which (roughly) doubles your scanning efforts, so it's much
more costly in terms of performance."
This comment can be found here:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1266193417
Cheers,
Ruben
On Fri, Sep 30, 2022 at 1:03 AM Ruben Somsen <rsomsen@gmail•com> wrote:
> Hi woltx,
>
> Excellent work.
>
> >Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead
>
> To expand on this, the scheme basically allows the resulting address to be
> recognizably marked (only recognizable by the recipient of course), which
> enables you to distinguish between different payment purposes (e.g. some
> people donate to you for purpose A, others for purpose B). Here's my
> original comment describing it:
>
> "Naively, the issue is that two keys means twice the scanning, but an
> interesting alternative would be to simply use the same key (assuming
> you're OK with using the same identity) but add a public identifier f to it
> when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*G
> . This means every additional "address" only costs one additional ECC
> addition when scanning (relatively cheap compared to doing ECC
> multiplications).
>
> The main downside with this is that f becomes crucial for recovering from
> backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
> remember how many "addresses" you issued (and perhaps overshoot when
> unsure) to ensure recovery of funds, though of course you'd rather also
> remember which index is associated with what payment reason.
>
> Absolute worst case scenario you could even do something similar to the
> gap limit where you scan the full history (not just the UTXO set so you
> don't miss spent outputs) with a default max index of e.g. 100, and then if
> you find out most of them are in use, you scan the next 100, etc. Costly,
> but thorough, and only needed as a last resort."
>
> Original comment here:
>
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
>
> Also good to note that f needs to be communicated to the sender somehow,
> perhaps as part of the address format.
>
> Cheers,
> Ruben
>
> On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>> 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 7480 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-10-03 23:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-29 22:19 [bitcoin-dev] Third version of Silent Payment implementation woltx
2022-09-29 23:03 ` Ruben Somsen
2022-10-03 23:41 ` Ruben Somsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox