📅 Original date posted:2016-03-08
📝 Original message:Our BIP just defines protocol definitions, and doesn't really dictate how
people use them (we're coming up with a new title for the BIP, by the way,
to more accurately convey that). Using our definitions as building blocks,
someone could definitely accomplish what you described. For example, Joe
Mobile Wallet User's wallet could upload a slew of generic PaymentRequest
messages with signatures to prove his identity, and the server could then
create encryptedPaymentRequest messages using the server's key for
encryption and communication with the other party. In this case the server
would essentially be a proxy for the user without having actual access to
the user's private keys.
My personal goal with the protocol was to keep it extremely flexible so
developers could use it to build all different types of schemes while
keeping standard messages that could be forwarded between services if
needed. Does the above make sense?
James
On Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is there a way for Joe Mobile Wallet User to upload a set of N
> PaymentRequests
> authenticated by his key to an untrusted server, which encrypts and passes
> them on in response to InvoiceRequests? Or does this necessarily require
> the
> recipient to be online?
>
> On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
> > The following draft BIP proposes an update to the Payment Protocol.
> >
> > Motivation:
> >
> > The motivation for defining this extension to the BIP70 Payment Protocol
> is
> > to allow 2 parties to exchange payment information in a permissioned and
> > encrypted way such that wallet address communication can become a more
> > automated process. Additionally, this extension allows for the requestor
> of
> > a PaymentRequest to supply a certificate and signature in order to
> > facilitate identification for address release. This also allows
> > for automated creation of off blockchain transaction logs that are human
> > readable, containing who you transacted with, in addition to the
> > information that it contains today.
> >
> > The motivation for this extension to BIP70 is threefold:
> >
> > 1. Ensure that the payment details can only be seen by the participants
> in
> > the transaction, and not by any third party.
> > 2. Enhance the Payment Protocol to allow for store and forward servers in
> > order to allow, for example, mobile wallets to sign and serve
> > Payment Requests.
> > 3. Allow a sender of funds the option of sharing their identity with the
> > receiver. This information could then be used to:
> >
> > * Make bitcoin logs more human readable
> > * Give the user the ability to decide who to release payment
> > details to
> > * Allow an entity such as a political campaign to ensure donors
> > match regulatory and legal requirements
> > * Allow for an open standards based way for regulated financial
> > entities to meet regulatory requirements
> > * Automate the active exchange of payment addresses, so static
> > addresses and BIP32 X-Pubs can be avoided to maintain privacy
> > and convenience
> >
> > In short we wanted to make bitcoin more human, while at the same time
> > improving transaction privacy.
> >
> > Full proposal here:
> >
> >
> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
> > .mediawiki
> >
> > We look forward to your thoughts and feedback on this proposal!
> >
> > Justin
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160308/069639e0/attachment-0001.html>;
James MacWhyte [ARCHIVE] /
npub12t…pye9h
2023-06-07 17:49:26
in reply to nevent1q…n75r
Author Public Key
npub12tjaqer27049ejmvf0f3yd7kq6p93gg6ecavgrczge4rlzf59y5q2pye9hPublished at
2023-06-07 17:49:26Event JSON
{
"id": "affdd14040bc4a45c2c3a4e3544fc0b29c3aba874cdbb18410c8853205ef9614",
"pubkey": "52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928",
"created_at": 1686160166,
"kind": 1,
"tags": [
[
"e",
"ff3b1720fa39794348520294c6f29261f76a38c44bc7269f9aef23028f8b7549",
"",
"root"
],
[
"e",
"1ef9b86b65cf21ea0fbbf73a00e58e922cec2ff2ce4f11d89e0f9a5b3b6d22f8",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-03-08\n📝 Original message:Our BIP just defines protocol definitions, and doesn't really dictate how\npeople use them (we're coming up with a new title for the BIP, by the way,\nto more accurately convey that). Using our definitions as building blocks,\nsomeone could definitely accomplish what you described. For example, Joe\nMobile Wallet User's wallet could upload a slew of generic PaymentRequest\nmessages with signatures to prove his identity, and the server could then\ncreate encryptedPaymentRequest messages using the server's key for\nencryption and communication with the other party. In this case the server\nwould essentially be a proxy for the user without having actual access to\nthe user's private keys.\n\nMy personal goal with the protocol was to keep it extremely flexible so\ndevelopers could use it to build all different types of schemes while\nkeeping standard messages that could be forwarded between services if\nneeded. Does the above make sense?\n\nJames\n\nOn Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Is there a way for Joe Mobile Wallet User to upload a set of N\n\u003e PaymentRequests\n\u003e authenticated by his key to an untrusted server, which encrypts and passes\n\u003e them on in response to InvoiceRequests? Or does this necessarily require\n\u003e the\n\u003e recipient to be online?\n\u003e\n\u003e On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:\n\u003e \u003e The following draft BIP proposes an update to the Payment Protocol.\n\u003e \u003e\n\u003e \u003e Motivation:\n\u003e \u003e\n\u003e \u003e The motivation for defining this extension to the BIP70 Payment Protocol\n\u003e is\n\u003e \u003e to allow 2 parties to exchange payment information in a permissioned and\n\u003e \u003e encrypted way such that wallet address communication can become a more\n\u003e \u003e automated process. Additionally, this extension allows for the requestor\n\u003e of\n\u003e \u003e a PaymentRequest to supply a certificate and signature in order to\n\u003e \u003e facilitate identification for address release. This also allows\n\u003e \u003e for automated creation of off blockchain transaction logs that are human\n\u003e \u003e readable, containing who you transacted with, in addition to the\n\u003e \u003e information that it contains today.\n\u003e \u003e\n\u003e \u003e The motivation for this extension to BIP70 is threefold:\n\u003e \u003e\n\u003e \u003e 1. Ensure that the payment details can only be seen by the participants\n\u003e in\n\u003e \u003e the transaction, and not by any third party.\n\u003e \u003e 2. Enhance the Payment Protocol to allow for store and forward servers in\n\u003e \u003e order to allow, for example, mobile wallets to sign and serve\n\u003e \u003e Payment Requests.\n\u003e \u003e 3. Allow a sender of funds the option of sharing their identity with the\n\u003e \u003e receiver. This information could then be used to:\n\u003e \u003e\n\u003e \u003e * Make bitcoin logs more human readable\n\u003e \u003e * Give the user the ability to decide who to release payment\n\u003e \u003e details to\n\u003e \u003e * Allow an entity such as a political campaign to ensure donors\n\u003e \u003e match regulatory and legal requirements\n\u003e \u003e * Allow for an open standards based way for regulated financial\n\u003e \u003e entities to meet regulatory requirements\n\u003e \u003e * Automate the active exchange of payment addresses, so static\n\u003e \u003e addresses and BIP32 X-Pubs can be avoided to maintain privacy\n\u003e \u003e and convenience\n\u003e \u003e\n\u003e \u003e In short we wanted to make bitcoin more human, while at the same time\n\u003e \u003e improving transaction privacy.\n\u003e \u003e\n\u003e \u003e Full proposal here:\n\u003e \u003e\n\u003e \u003e\n\u003e https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension\n\u003e \u003e .mediawiki\n\u003e \u003e\n\u003e \u003e We look forward to your thoughts and feedback on this proposal!\n\u003e \u003e\n\u003e \u003e Justin\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160308/069639e0/attachment-0001.html\u003e",
"sig": "2b425366fd547612cabd9679aa6c11c6b94644f3bad816ee07c9d54e48d5d972ded1299df904a130df28f7be35b2ee87735b773c5331e60c23fb4f6a7f5af870"
}