What is Nostr?
Pieter Wuille [ARCHIVE] /
npub1tje…tl6r
2023-06-07 02:59:53
in reply to nevent1q…qhc4

Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2012-01-31 📝 Original message:On Tue, Jan 31, 2012 at ...

📅 Original date posted:2012-01-31
📝 Original message:On Tue, Jan 31, 2012 at 10:01:00AM +0000, Gary Rowe wrote:
> Personally, I feel that simple is best and while a block number represents
> Bitcoin's pulse, there is no guarantee that a block will be discovered at
> any particular moment. From a merchant perspective the main point of the
> expires field is to limit risk against currency movement (immediate cash
> out) or inventory movement (time limited offer). I have difficulty seeing a
> good use case that would need a block. People have been co-ordinating
> events based on a UTC timestamp for decades and I think we should stick
> with it.

For merchant purposes, I believe URI's containing a static pubkeyhash-address
are only a temporary solution until more elaborate solutions that deal with
all concerns appear (tagging transactions, feedback to the merchant, making
the receiver responsible for inclusion, certificates that a payment was
accepted, authentication, ...). I believe static addresses are too limited
for this purpose, and we shouldn't be trying to extend them with too many
features.

There have been discussions about more dynamic approaches (such as HTTP
communication to negotiate an address) here, and I've written my own
proposal as well (https://gist.github.com/1237788). The details are not
really relevant at this time, but these dynamic approaches seem a much
better way of dealing with what you're trying to add to the bitcoin URI
system now.

My 2 cents: keep bitcoin URI's simple for now.

--
Pieter
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r