What is Nostr?
kjj [ARCHIVE] /
npub1t9t…6cf0
2023-06-07 02:28:34
in reply to nevent1q…zpq6

kjj [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-23 🗒️ Summary of this message: Pieter Wuille ...

📅 Original date posted:2011-09-23
🗒️ Summary of this message: Pieter Wuille proposes moving away from static bitcoin addresses as descriptions for transactions. However, some argue that this solution is convoluted and unnecessary.
📝 Original message:Pieter Wuille wrote:
> Hello everyone,
>
> here is an idea i've bean writing up: https://gist.github.com/1237788
>
> I hope it can start some discussion about moving away from static bitcoin addresses
> as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/...,
> but as things don't seem to have been decided completely about those, I put it in a
> Gist.
>
> Please, comment.
>
This may just be me, but this really looks like an incredibly convoluted
way to solve a bunch of problems that aren't really problems. The
central issue that I see, is that you assume that there is no out of
band channel, as if people were just sending transactions to addresses
that came to them in a dream.

I think that this assumption is only true when it doesn't matter. For
example, I have a donation link in my sig on the forums. I don't care
much who sends to it, or why, and I certainly don't need annotations or
a refund address. The rest of the time, payments are sent to addresses
that already have sufficient context.

Only one of the advantages listed is actually an advantage. That is
that payments to stale addresses can be stopped. This isn't much of an
advantage though, as someone blindly sending payments (donations,
really) to addresses found on backup tapes and web archives without
verifying that they are still current kinda deserve what they get. So
it really only stops payments to services that go defunct the same day
(more or less).

In the end, I just don't see the value in giving a URL so that I can go
ask a server for information that could just as easily have been encoded
in the URL directly.

Then again, I'm cynical, and didn't sleep very well last night. Maybe
the next person will think better of it.
Author Public Key
npub1t9txg5aevth45pu9hcz075tj3ch25fydn8c38wew90qjjdjv3rqq3r6cf0