📅 Original date posted:2023-08-05

🗒️ Summary of this message: Adding a field to silent payment addresses to encode expiration dates is suggested, with different byte lengths for different granularities.

📝 Original message:

On Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote:

> I agree. Non-expiring addresses are a significant risk to bitcoin users.

>

> On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:

> > Fixing this is easy: add a 3 byte field to silent payments addresses, encoding

> > the expiration date in terms of days after some epoch. 2^24 days is 45,000

> > years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180

> > years. We'll be lucky if Bitcoin still exists in 180 years.

>

> Instead of a fixed width nDays, consider a custom compact encoding with

> the position of the first 0-bit indicating the number of extension bytes

> and the encoded granularity.

>

> bytes | prefix | usable bits | granularity | max expiration

> ------|------------|-------------|-------------|---------------

> 1 | 0b0 | 7 | year | 128 years

> 2 | 0b10 | 14 | week | 315 years

> 3 | 0b110 | 21 | day | 5700 years

> 4 | 0b1110 | 28 | block | 5100 years

> 5 | 0b11110 | 35 | ??? | ???

> 6 | 0b111110 | 42 | ??? | ???

> 7 | 0b1111110 | 49 | ??? | ???

> 8 | 0b11111110 | 56 | ??? | ???

>

> For address expiration, year or week expiration will typically be

> sufficiently granular, but for rare occasions more granularity can be

> encoded with longer addresses. This method also degrades cleanly even if

> the same address format is still in use in 100 or 300 years.

1) Having the granularity of the limit depend on *when* the limit is to be

applied in a UX nightmare. It is far simpler to just pick a useful granularity,

and include enough bytes of integer to work until well into the future. 3

bytes, 24-bits, of days is 45,000 years. That's plenty.

2) Your suggestion would result in a protocol that degrades over time, as the

granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,

where we're creating something now with a limit in the future. 100 years from

now - if silent payments still exists - people will still want to create silent

payment addresses that expire, say, 30 days in the future. Your suggestion does

not allow that.

--

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: not available

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/82374bb3/attachment.sig>

📅 Original date posted:2023-08-05

🗒️ Summary of this message: Samson Mow questions the 180-year limit for planning, suggesting a longer timeframe, and provides examples of historical inventions.

📝 Original message:

On Fri, Aug 04, 2023 at 11:41:39AM -0700, Samson Mow wrote:

> Why the 180 year limit? imho should plan for longer.

You know, it was only 137 years ago that the first practical electric motor was

invented; 143 years ago that the first practical light bulb was invented.

180 years is a long time.

But if that seems too short, as I said, 3 bytes is sufficient for 45,934 years.

The invention of agriculture is only 12,000 years old. Although I guess as a

toxic bitcoin carnivore you care more about the invention of the bow and arrow,

70,000 years ago.

--

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: not available

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/e99335b2/attachment.sig>

📅 Original date posted:2023-08-04

🗒️ Summary of this message: Silent Payment addresses, which allow for multiple payments without privacy concerns, should have an expiration date to prevent funds from being lost forever. Adding a 3-byte field to encode the expiration date is a simple solution. Wallets should have a default expiration date and attempts to pay an expired address should fail.

📝 Original message:

tl;dr: Wallets don't last forever. They are often compromised or lost. When

this happens, the addresses generated from those wallets become a form of toxic

data: funds sent to those addresses can be easily lost forever.

All Bitcoin addresses have this problem. But at least existing Bitcoin

addresses aren't supposed to be reused. Silent Payments are: the whole point is

to have a single address that you can safely pay to multiple times, without

privacy concerns. Failing to make Silent Payment addresses eventually expire in

a reasonable amount of time is thus a particularly harmful mistake.

Fixing this is easy: add a 3 byte field to silent payments addresses, encoding

the expiration date in terms of days after some epoch. 2^24 days is 45,000

years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180

years. We'll be lucky if Bitcoin still exists in 180 years.

Wallets should pick a reasonable default, eg 1 year, for newly created

addresses. Attempts to pay an expired address should just fail with a simple

"address expired". Lightning invoices are a good example here: while invoices

does not require expiration from a technical point of view, they do expire for

similar UX reasons as applies to silent payments.

--

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: not available

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/70c37a09/attachment.sig>

📅 Original date posted:2023-08-01

🗒️ Summary of this message: Daniel Lipshitz argues that the research is flawed and reaches an incorrect conclusion. He provides evidence of Coinspaid's use of 0-conf and offers to connect with Max, the CEO, for confirmation. He also mentions Changelly's offer to confirm GAP600 as a service provider. However, the request for concrete examples of merchants relying on unconfirmed transactions remains unanswered.

📝 Original message:

On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:

> Your research is not thorough and reaches an incorrect conclusion.

>

> As stated many times - we service payment processors and some merchants

> directly - Coinspaid services multiple merchants and process a

> significant amount of BTC they are a well known and active in the space -

> as I provided back in December 2022 a email from Max the CEO of Coinspaid

> confirming their use of 0-conf as well as providing there cluster addresses

> to validate there deposit flows see here again -

> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html

> - if this is not sufficient then please email support at coinspaid.com and ask

> to be connected to Max or someone from the team who can confirm Conspaid is

> clients of GAP600. Max also at the time was open to do a call, I can check

> again now and see if this is still the case and connect you.

>

> That on its own is enough of a sample to validate our statistics.

Why don't you just give me an example of some merchants using Coinspaid, and

another example using Coinpayments, who rely on unconfirmed transactions? If

those merchants actually exist it should be very easy to give me some names of

them.

Without actual concrete examples for everyone to see for themselves, why should

we believe you?

> I have also spoken to Changelly earlier today and they offered to email pro

> @ changelly.com and they will be able to confirm GAP600 as a service

Emailed; waiting on a reply.

> provider. Also please send me the 1 trx hash you tested and I can see if it

> was queried to our system and if so offer some info as to why it wasnt

> approved. Also if you can elaborate how you integrated with Changelly - I

> can check with them if that area is not integrated with GAP600.

Why don't you just tell me exactly what service Changelly offers that relies on

unconfirmed transactions, and what characteristics would meet GAP600's risk

criteria? I and others on this mailing list could easily do test transactions

if you told us what we can actually test. If your service actually works, then

you can safely provide that information.

I'm not going to give you any exact tx hashes of transactions I've already

done, as I don't want to cause any problems for the owners of the accounts I

borrowed for testing. Given your lack of honesty so far I have every reason to

believe they might be retalliated against in some way.

> As the architect of such a major change to the status of 0-conf

> transactions I would think you would welcome the opportunity to speak to

> business and users who actual activities will be impacted by full RBF

> becoming dominant.

Funny how you say this, without actually giving any concrete examples of

businesses that will be affected. Who exactly are these businesses? Payment

processors obviously don't count.

> Are you able to provide the same i.e emails and contacts of people at

> the mining pools who can confirm they have adopted FULL RBF ?

I've already had multiple mining pools complain to me that they and their

employees have been harassed over full-rbf, so obviously I'm not going to

provide you with any private contact information I have. There's no need to

expose them to further harassment.

If you actually offered an unconfirmed transaction guarantee service, with real

customers getting an actual benefit, you'd be doing test transactions

frequently and would already have a very good idea of what pools do full-rbf.

Why don't you already have this data?

--

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: not available

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment.sig>