📅 Original date posted:2011-12-15
🗒️ Summary of this message: The server can get the recipient's address in various ways, including a static address, generating a new one for each payment, or managing a set of addresses. Best practices can be used instead of standardizing the transparent part of the process. The use of <meta> tags or Bitcoin URI can be used for the format.
📝 Original message:> But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.
> -The servers stores the recipient private keys and generates a new one
> for each payment.
> -The server stores a set of addresses provided by the recipient and it
> manages what address it gives in each request (like in the web service
> I told you I can't find).
>
Exactly, I think we should starting separating the minimal protocol that is
to be supported by everybody, and the rest can be summed up in a few best
practices, no need to standardize the part that to the user is transparent.
I was on the same lines as Andy, which is that in order to have require a
payment I probably have an order/transaction pending with my vendor or have
an account to be filled, so there's a 1-to-1 mapping between the details
page and the bitcoin address I have to send to.
As a further possibility we could use <meta> tags like the OpenID server
delegation mechanism. It would allow customers to open the transaction
details page, see that everything is ok, then paste the same URL into the
bitcoin client, the bitcoin client retrieves the URL, parses the meta tag
and knows what to send where. Alternatively the Bitcoin Client sends an
Accept header which tells the server to return just the address.
As for the format I'd say either a Bitcoin address or a Bitcoin URI [1]
which ought to be flexible enough as it includes amount and messages, for
the customer to be able to track transactions.
Regards,
Chris
[1] https://en.bitcoin.it/wiki/URI_Scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/c44d2b60/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 02:47:28
in reply to nevent1q…jpvm
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 02:47:28Event JSON
{
"id": "3082d31342678e7c3dcd7f0ed8a00b9316e50c57115398d655ce04129375bca4",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686106048,
"kind": 1,
"tags": [
[
"e",
"f45e7ca88e6eb3dd1e645e8e3cbb476c5b24e8003cb71eebe205594bb2a4d152",
"",
"root"
],
[
"e",
"37b9e59da932c3924ae6781105bbf0920efd4205eb891a22d2293448ebebe055",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2011-12-15\n🗒️ Summary of this message: The server can get the recipient's address in various ways, including a static address, generating a new one for each payment, or managing a set of addresses. Best practices can be used instead of standardizing the transparent part of the process. The use of \u003cmeta\u003e tags or Bitcoin URI can be used for the format.\n📝 Original message:\u003e But we don't have to\n\u003e define how the server will get that address.\n\u003e Some possibilities:\n\u003e\n\u003e -A static address: less anonymity, but some people may not care. Say a\n\u003e donation address.\n\u003e -The servers stores the recipient private keys and generates a new one\n\u003e for each payment.\n\u003e -The server stores a set of addresses provided by the recipient and it\n\u003e manages what address it gives in each request (like in the web service\n\u003e I told you I can't find).\n\u003e\n\nExactly, I think we should starting separating the minimal protocol that is\nto be supported by everybody, and the rest can be summed up in a few best\npractices, no need to standardize the part that to the user is transparent.\nI was on the same lines as Andy, which is that in order to have require a\npayment I probably have an order/transaction pending with my vendor or have\nan account to be filled, so there's a 1-to-1 mapping between the details\npage and the bitcoin address I have to send to.\n\nAs a further possibility we could use \u003cmeta\u003e tags like the OpenID server\ndelegation mechanism. It would allow customers to open the transaction\ndetails page, see that everything is ok, then paste the same URL into the\nbitcoin client, the bitcoin client retrieves the URL, parses the meta tag\nand knows what to send where. Alternatively the Bitcoin Client sends an\nAccept header which tells the server to return just the address.\n\nAs for the format I'd say either a Bitcoin address or a Bitcoin URI [1]\nwhich ought to be flexible enough as it includes amount and messages, for\nthe customer to be able to track transactions.\n\nRegards,\nChris\n\n[1] https://en.bitcoin.it/wiki/URI_Scheme\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111215/c44d2b60/attachment.html\u003e",
"sig": "be724704a44dd3787e056c8453295a76cfc69ea780b02bbd9fbfa65afdad8d6325d2695a32dfc897a021d39d9d1b99f308144a9b1f55817f72dc649a779962c2"
}