Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-15 🗒️ Summary of this message: The BIP15 ...

📅 Original date posted:2011-12-15
🗒️ Summary of this message: The BIP15 standard should set the format of the client-server conversation, not the URI format, as interaction is necessary for generating temporary addresses. An aliasing server can give a single, unchanging, well-known label to a transacting party, but still enable that party to generate a new address per transaction. Anonymity is already lost in a supplier-client relationship, and any aliasing scheme necessarily reduces anonymity.
📝 Original message:On 2011 December 15 Thursday, Walter Stanish wrote:

> > Andy sounded very convincing when talking in favor of URLs. What's
> > wrong with his proposal?
>
> A URI identifies a resource and is in effect an alias itself.
> Identifying a resource is different from interacting with it. So,
> while <resource-type>://<resource-type-specific-alias> will work
> sufficiently for the identification, it does not explain the
> interaction.

Quite so; the BIP15 standard shouldn't be setting the format of the URI; it
should be setting what the format of the client-server conversation is.
Effectively, what headers will a requesting client send? What headers should
a server require? What will a server respond?

> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.

I think that's missing the point; any aliasing scheme is definitely reducing
your anonymity, neccessarily so -- the alias has to be looked up somewhere,
that somewhere reduces anonymity. If anonymity is what you want, stick with
just a bitcoin address. The point of an aliasing server is surely to be able
to give a single, unchanging, well known label to a transacting party, but
still enable that party to generate a new address per transaction.

I want my webshop to be able to say "please pay 3.20 BTC to
https://mywebshop.com/payments/orderid=27282"; to enable the automatic
connection from orderid to bitcoin address (which my payment system can then
monitor for payment receipt). (This is just one example).

> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).

Well yes; but then the client has no idea what address to send to unless it
connects to that URI... interaction/address generation is done when that
connection is made.

In short: I don't really think that this aliasing system should be concerning
itself with preserving anonymity of the receiving party. That is almost
certainly already gone (I'm hardly likely to send money to someone I don't
know unless I like gifting random cash). The sending party loses a little
anonymity because their IP is revealed when they connect to the aliasing
system. But there is very little anonymity in a supplier-client relationship
anyway (you have to say what goods you want, and where you want them, and you
had to interact with a website when you were ordering already).



Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/74e9c385/attachment.sig>;