Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Alan Reiner etotheipi at gmail.com writes: On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen gavinandresen at gmail.com wrote:When I say pass around I'm not thinking of users copying and pasting, that would be a terrible user experience; all of that communication needs to happen automatically behind the scenes. Lets tackle that after we've got the simpler customer-pays-merchant flow working nicely (funded-escrow-pays-merchant is a subset of that, anyway). I think that the pass around method needs to happen in addition to the methods of transparent protocols that occur behind the scenes. For one, there's a lot of CONOPs that need to be worked out by getting knowledgeable people using it, and providing feedback about how it could/should/will be used and how it could be improved. The pass-around method is simpler to implement and still usable by the types of users that will be using it in the beginning -- experts. Also, I see that for very large, important multi-sig tx/contracts/escrow, the manual method might be preferred -- much the same way many people prefer manual-transmission cars even though automatics are easier -- some people/organizations will want the control. I'm all for protocols that enable higher-level access to this functionality, I'm just saying there should be lower-level access, too. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development Another online space wagering stage has been propelled and targets Bitcoin, Litecoin and Dogecoin fans from everywhere throughout the world. Presented in August, Crypto-Games.net is a straightforward space machine diversion that might be immediately played in any web program with the utilization of cryptocurrencies, making it one of the first few wagering destinations that are intended for Slot machine betting. As indicated by its site, it emphasizes a four-reel space machine with one pay line that acknowledges wagers measuring from 50 Credits to a greatest of 9,999 Credits, where playing with most extreme wager yields a gigantic big stake of 4,999,500 Credits. Then, the store exchange routines for this opening machine amusement have been created to be productive with the stores taking online 2 to 10 minutes to be transformed and the withdrawals just 6 to 60 minutes without any transaction charges. Moreover, a QR code has as of now been added to suit versatile bettors utilizing their cell phones and tablets. Also, the administrators have taken the additional mile to guarantee reasonableness by depending on the random.org API to deliver genuine arbitrariness that supplements the diversion's reasonable calculation. The https://www.crypto-games.net opening diversion, on the other hand, cautions players to observe their remarkable ID number to abstain from losing access to their account. This is essential on the grounds that Crypto-Games does not oblige any type of record enlistment; rather, it composes into cookies, which are erased following 14 days. Besides, it has taken off new extra arrangements for Crypto bettors aside from the 25% house edge that are up for gets through the referral system. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On 2012-12-21 17:05:21 +, Stephen Pair said: Also, identity is one thing, an elaborate trust based identity verification system (like CA's) is a whole other thing. Your distinction between identity and trust-based identity is one of the most important insights to emerge from this thread. Thank you for pointing this out. the first task at hand is to implement secure, private messaging... it's easy to do and you don't need to solve the PKI problem. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
I hope that this input does not come too late; I haven't had time to review
the proposal until now.
For alt-chains that have time-varying value (Freicoin[1], currently), it is
necessary in some applications to include a reference height in the
invoice. Since the bitcoin protocol does not assume a universally
agreed-upon time source, Freicoin (and presumably other
yet-to-be-implemented time-varying chains) uses blocktime as the clock for
time-value calculations: outputs lose 2**-20 of their value with each
passing block. The reference height for an invoice is the blocktime at
which amount values are specified and the reference point for time-varying
calculations. As a concrete example, an invoice for payment of 50 frc today
could be satisfied by 49.99313402 frc tomorrow.
To implement this, we would require an optional uint64 refheight field in
the invoice structure. refheight or nRefHeight is what we call this
value internally, but blocktime or blockheight would work as well.
Github is currently down, so I apologize if a suitable field has already
been added.
Cheers,
Mark Friedenbach
[1] http://freico.in/ Freicoin: a P2P digital currency delivering freedom
from usury.
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen gavinandre...@gmail.comwrote:
This is the next big lets all agree to do things the same way thing
I think we should tackle. I'm particularly looking for feedback from
other bitcoin client developers, even if it is just a quick looks
reasonable, if everybody else is going to do it then I will
(eventually) too...
Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
suggestions and brainstorming.
This document is online at https://gist.github.com/4120476
If you respond to this message, please be considerate of people who
subscribe to the digest version of this mailing list and trim your
response.
Invoices, Payments and Receipts for Bitcoin Transactions
This document proposes protocol buffer-based formats for signed,
authenticated invoices and receipts -- requests for payment, and
proof-of-payment.
Separate documents propose an extension to the Bitcoin URI syntax and
new MIME types to support them.
Motivation
==
The idea of a payment protocol to improve on Bitcoin addresses has
been around for over a year. Users have been asking for some features
in this proposal (like the ability to provide a refund address so
overpayments or refunds can be returned to customers without the need
to ask them for their address) for two or three years, and have
started to work around shortcomings in the Bitcoin payment process
with creative (but inefficient) uses of transactions.
The key features of this proposal are:
+ Requests for payment (Invoices) are tied to authenticated identities
using the only widely-deployed identity authentication system we have
right now (X.509 certificates signed by root certificate authorities)
+ Invoices include a user-friendly description of what the payment is for
+ Payments include where refunds should be sent
+ At the end of the payment process, the customer holds a
cryptographically signed Receipt that can be used as proof-of-payment
if there is any dispute with the merchant.
Specification
=
Invoice/SignedInvoice
-
An Invoice is a request for payment from a merchant to a customer:
::
message Output {
optional uint64 amount = 1;
required bytes script = 2;
}
amount: Number of satoshis (0.0001 BTC) to be paid. If not given
or zero, then the customer will be asked how much to pay.
script: a TxOut script to which the customer should direct payment.
This will normally be one of the standard Bitcoin transaction script
(e.g. pubkey OP_CHECKSIG).
::
message Invoice {
repeated bytes x509chain = 1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}
outputs: one or more outputs where Bitcoins are to be sent.
x509chain: one or more DER-encoded X.509 certificates that identifies
the merchant. See the Certificates section below for details.
time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was
created.
expires: Unix timestamp after which the Invoice should be considered
invalid. If not given, the Invoice may be re-used until the earliest
certificate expiration date in the X509chain.
single_use: If true, this Invoice should be used for only one payment.
If false, it may be added to the user's address book and used
repeatedly until it expires (e.g. for donations or a recurring
payment).
memo: UTF-8 encoded, plain-text (no formatting) note that should be
displayed to the customer, explaining what this
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Here are my (mostly half baked) thoughts on the payments protocol proposal. My first observation is that the proposal is too heavily oriented around a merchant/customer interaction. I think it's equally important to consider the person to person scenarios. It would be very cool if people could send/receive payments by copying and pasting stuff on facebook or email (you can kind of do it now, but it's not safe unless you go to extraordinary lengths using PGP signatures and the like). Protobufs vs JSON: Protobufs are fine, although I will mention that the serialization/JOSE arguments are irrelevant...you only need that if you need a reliable way of signing an in memory object structure...in this case you would be signing a serialized form of the object...the recipient doesn't have to be able to reproduce the serialized form, they only need to verify the signature on the already serialized bytes...I see protobufs as a good serialization format for storage, while JSON being more practical for communications in a web oriented environment...with protobufs a web wallet, you may find yourself in a situation needing to parse a protobuf message in a web browser...the protobuf parsing and serializing code is just going to add bloat to the web page...personally, I probably would have gone with JSON, but hey, I'm not writing the code. X.509 - nasty, but maybe ok ...as long as you can add root CAs to your Bitcoin client or explicitly trust a certificate, I don't see that it poses any privacy issues...but there are some other things to think about here ...like what about the casual user that wants to create a payment request to send to their friend over email (wrapped in a clear text block similar to PGP...it could also be sent as a file attachment)? Are you now requiring them to go and setup a certificate? Btw, I really like the use of a payment request in this manner because you have a signed payment request that can be verified against an address book of known identities. This could be much safer than simply emailing an unsigned bitcoin address around. Refund addresses...this is not going to be as useful as people might think...most refunds that bitpay needs to process happen days or even months after the initial purchase...in that span of time, people can change wallets, rendering such a refund address useless...so, as I think about the situation, we would still need to contact the buyer to confirm a refund address anyway. What we really need is to verify the identity of the person we're potentially sending the refund to...we need a way of determining that the person we're sending the refund to is the same person that paid the original invoice. Bitcoin addresses are identities, but they are too low level. HD wallets come to mind...the top level or intermediate levels of a deterministic hierarchy could be used for identity purposes...but it also seems like it might be conflating payments and identity (which for many reasons you might want to keep separate). What if bitcoin clients could manage one or more identities used for the purpose of communications? You could have a bitcoin identity file that could be used by multiple wallets. These identities would be used for signing messages and verifying the authenticity of communications...when sending a payment, instead of a refund address, you would include one of these identities which could later be used to confirm a refund address. In fact, the refund would be processed by the buyer generating another payment request message signed by the identity used in the original payment. People would understand that their identities are important for communications and they would keep those even when changing to new wallets and such (identities could be stored in ~/.bitcoin/id or something (encrypted of course)). There are some other interesting possibilities if messaging and identities are done right...for example, I could add check feature (analogous to paper checks). It would work like this...you create a transaction that spends to a newly generated address...you put that transaction, along with the private key into an encrypted container (sent to the identity of the person you want to pay). The recipient can open it and their wallet would go ahead and generate and broadcast a transaction moving the funds into their wallet (optionally including a fee). But, if the recipient never cashes the check, the sender could pull those funds back after a certain period of time. This also eliminates the possibility of accidentally sending the funds to the wrong address (or an old address) and the bitcoins being forever lost...the recipient can sweep the transaction into any wallet of their choice. As I'm writing this, I'm beginning to wonder if the identity management problem is unavoidable. Maybe that needs to be dealt with first. It would enable so many other interesting possibilities. I like the use of merchant_data...this means that you no longer will need
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Thanks for the thoughts. For those who don't know, Stephen works for BitPay. My first observation is that the proposal is too heavily oriented around a merchant/customer interaction. The term merchant is just being used to mean the entity requesting the payment. I'm hopeful that in future mobile wallets will be creating these messages where today they'd make URLs and QRcodes. So it's definitely intended for person to person payments too. you may find yourself in a situation needing to parse a protobuf message in a web browser Nothing stops you converting them into whatever form you want on the server side. If you don't care about the signature checking then it's no problem to use a server. If you do then you'd need to ship all the code for verifying signatures that to the client anyway, at which point a small protobuf parser is hardly a deal killer. ...like what about the casual user that wants to create a payment request to send to their friend over email They can send an unsigned payment request. Note that if you mail it as an attachment from a competent, up to date email provider then the attachment isn't really unsigned. The whole thing is covered by the emails DKIM signature which is applied transparently by the ESP. If the signature fails to verify then the mail client can show that or treat the mail differently (as Gmail does). This is easy to use for the end user - they don't have to think about cryptography or PKI. As long as their email account is secure then they can send signed mails asserting to their identity. Refund addresses...this is not going to be as useful as people might think...most refunds that bitpay needs to process happen days or even months after the initial purchase Useful feedback, thanks. Still, there may be other types of merchants for whom it's useful, and many users won't change their wallet. It certainly simplifies things if you can present the refund address and give a one-click option to use it. If the user wants to use a different address, then they can go onto the slow/complicated path. This current spec deliberately punts on the topic of identifying end users. It's a difficult problem. Whereas many merchants have SSL certs, most end users don't have published keys in any useful form. By far the easiest way for 99% of people to generate a signed message is to send email that's signed by DKIM (from gmail, hotmail, yahoo, other providers etc). Then it's all transparent and behind the scenes. Their identity is their email address. So for BitPays scenario, you could require an email to be sent by the end user containing new instructions. Your MTA can show you whether the mail is correctly DKIM signed or not when deciding whether to follow the instructions. But, if the recipient never cashes the check, the sender could pull those funds back after a certain period of time. Yeah, I like the term check/cheque for that concept of a reversible payment. I like the use of merchant_data...this means that you no longer will need a unique bitcoin address for every invoice. It's still a good idea to use one for privacy reasons. The merchant data is there so you can stuff whatever state you want into it. So it's like cookies. You don't have to keep state on the server side. Just encrypt/sign it, put it in the invoice, and when you get a payment message back there's no need to do database lookups or anything, you can just do some crypto and know who is submitting it. Generally speaking, I'm not a fan of embedding things like that What's wrong with it? Isn't your proposal more complex? I don't see why it's better than just embedding it. The Receipt should be signed...it could be used as proof of payment by wallets. There's no Receipt message, a SignedPaymentRequest + transactions that pay to the requested outputs are together the proof of payment. Re a new URI scheme. Interesting idea, thanks for the suggestion. It seemed like it'd be easier for merchants to integrate if a single linked worked for all wallet implementations/versions. But I guess we could do both schemes, even. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn m...@plan99.net wrote: you may find yourself in a situation needing to parse a protobuf message in a web browser Nothing stops you converting them into whatever form you want on the server side. If you don't care about the signature checking then it's no problem to use a server. If you do then you'd need to ship all the code for verifying signatures that to the client anyway, at which point a small protobuf parser is hardly a deal killer. No, it's not a killer...just a hassle. JSON is convenient and ubiquitous and there is something to be said for that (and I wanted to point out that the JOSE objection was invalid). Protobufs are nice and efficient, but who cares. You're talking about direct communications rather than something that will be bounced around every node in the mesh network. I don't really care much either way, it's not worth debating. I'm just thankful no one is arguing for XML or IIOP. :) ...like what about the casual user that wants to create a payment request to send to their friend over email They can send an unsigned payment request. Note that if you mail it as an attachment from a competent, up to date email provider then the attachment isn't really unsigned. The whole thing is covered by the emails DKIM signature which is applied transparently by the ESP. If the signature fails to verify then the mail client can show that or treat the mail differently (as Gmail does). This is easy to use for the end user - they don't have to think about cryptography or PKI. As long as their email account is secure then they can send signed mails asserting to their identity. This leaves too much to chance for my taste. Forget email, what about jabber, ICQ, skype, IRC? Email is just one communications medium, there are many others for which there would be no assurance that the payment request hasn't been tampered with. You could at a minimum allow a person to create a normal ECC key, but have it used as an identity in communications rather than a payment address. You store it in a separate file in ~/.bitcoin/id ...you don't have to solve the whole set of PKI problems, people could exchange identities using any secure channel they are comfortable with (email + phone verification of a short hash id would be sufficient). In another scenario, an id could be made available over https, using the normal SSL certificate and CA infrastructure to verify authenticity. This way all messages could be signed and/or encrypted without the user having to go out of their way to use external tools or infrastructure that is often not very user friendly. You also need encryption for the cheque feature...asking people to use GPG would be too much of a burden (and email DKIM doesn't offer encryption). wandering off topic Indeed, cheques could become the dominant method of person to person payments...first, you would obtain someone's id, which you might already have on file (rather than obtaining a bitcoin address), then you would generate a cheque for the amount desired and send it to them...the recipient then has full control over what address they want to sweep the funds to as well as whether they'd like to include a miner fee to speed the confirmation along. Despite the fact that you may send many payments to the same identity, the only thing showing up on the p2p network and the block chain is the one time use address for the cheque and the recipient's wallet address. This means the recipient has much more control over the address policy used (compared with simply giving out a bitcoin address that may be reused). Refund addresses...this is not going to be as useful as people might think...most refunds that bitpay needs to process happen days or even months after the initial purchase Useful feedback, thanks. Still, there may be other types of merchants for whom it's useful, and many users won't change their wallet. It certainly simplifies things if you can present the refund address and give a one-click option to use it. If the user wants to use a different address, then they can go onto the slow/complicated path. This current spec deliberately punts on the topic of identifying end users. It's a difficult problem. I know, but as I was responding, I began to realize this is a mistake. It's worthwhile to tackle that problem first...if done right, it would pay huge dividends. Also, identity is one thing, an elaborate trust based identity verification system (like CA's) is a whole other thing. I think the former is pretty simple actually...and it's all that's really needed for the time being (as I alluded, a bitcoin identity could be communicated or verified using the existing X.509/CA infrastructure if desired...you could also use the PGP infrastructure). I like the use of merchant_data...this means that you no longer will need a unique bitcoin address for every invoice. It's still a good idea to use one
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On 17 December 2012 03:18, Jeff Garzik jgar...@exmulti.com wrote: On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho melvincarva...@gmail.com wrote: On 3 December 2012 20:35, Mike Koss m...@coinlab.com wrote: It would also be really nice to migrate to textual representations of data structures as opposed to binary ones. The most successful internet standards are based on text, making them that much more accessible for developers to deal with them. JSON would be my preferred candidate. Why don't we sign the text representation of a (utf8) JSON, rather than some complex encoding standard of JSON? That way the signatures are simple - and you need only retain the original textual representation of a message to validate the signature (as well as the decoded version, if you don't want to alway re-parse the message when writing programs that use it). Binary formats can be challenging to deal with and convert to other formats. The experiences in the PKI world of ASN.1 have not been great, in terms of interop. It tends to create islands and silos. This is probably one of the reasons why X.509 and GPG are fragmented and why we dont really have a widely deployed web of trust on the net. Another reason is simply lack of developer resources to make tools. In that respect I think JSON offers significant advantages, though I am interested in the security issues raised. I thought this had already been covered up-thread? When creating something that must be hashed and/or compared, the data structure must be created and reproduced precisely, byte-for-byte. JSON offers significant -disadvantages- in this regard. With JSON, you would therefore require an additional middle layer, between JSON and application, ensuring that all fields are output in the same order, all whitespace is not only perfectly preserved -- but reliably generates identical whitespace output for identical inputs, given two separate JSON implementations. Apologies if I am a bit late to the thread. I bumped into someone that suggested I take a look at it. Will try and catch up! You raise a good point. Is there no good canonicalization algorithm / library for JSON? I think that provided that each JSON object has an identifier, canonicalization of JSON is not that hard. Then when you hash or sign the canonical form they can be compared reliably. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
I've been following this thread closely, and Mike is correct here - protocol buffers is definitely the way to go. On 17 December 2012 09:19, Mike Hearn m...@plan99.net wrote: Can we please drop the binary vs text issue? We have been around it millions of times already. There are no compelling arguments to use text here and several obvious problems with it. If you think you've found a good argument to use JSON, please research protocol buffers more thoroughly and see if it changes your mind. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On 17 December 2012 10:19, Mike Hearn m...@plan99.net wrote: Can we please drop the binary vs text issue? We have been around it millions of times already. There are no compelling arguments to use text here and several obvious problems with it. If you think you've found a good argument to use JSON, please research protocol buffers more thoroughly and see if it changes your mind. Hi Mike, thanks you for the pointer. I have read up on Protocol Buffers. If the decision has already been made, then let's go with that, but if not perhaps I can offer some comments. Looking at: http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats And -- Canonically, Protocol Buffers are serialized into a binary wire format which is compact, forwards-compatible, backwards-compatible, but not self-describing I can see there are advantages in this approach in that you can send messages quickly and with low bandwidth. However the non self describing data means that it's significantly harder to convert from one format to another. Also references are important, and can be achieved in JSON. Yet in my opinion there is great advantage to growing the bitcoin ecosystem to interoperate with the whole net, kind of creating a complete web economy. The way to do this is to foster interoperability. Having looked at and worked with standards for the past 5-10 years that is the great challenge. Every system works in an island, and few talk to any others. However, a market based economy grows exponentially more valuable with extra liquidity. Inventing yet another format may lead to balkanization. If history is a judge, the chances are high. A self describing JSON format, however is much more likely to interop. I can understand the hesitation with JOSE. However, if you get a moment, please look at : http://payswarm.com/specs/source/web-keys/ This should provide some of the tools that you need. As I said above, if the matter is closed, that's fine and thanks for taking the time to read. Can I at least propose to make it mandatory for the binary format to have a translation script to a self describing JSON format and back again. I would love to see the bitcoin ecosystem become a major part of the infrastructure of the web itself (leading to even nice things like a proper web of trust), as well as an awesome P2P system in its own right. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Dec 17, 2012 at 6:23 AM, Melvin Carvalho melvincarva...@gmail.comwrote: If the decision has already been made, then let's go with that The decision has already been made. -- -- Gavin Andresen -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On 3 December 2012 20:35, Mike Koss m...@coinlab.com wrote:
The thing that bugged me most about the original spec was the sole
reliance on X.509 - glad to see you've made that optional. I think many
people will balk at deferring our identity trust to the existing CA's. I
think it's a fine bootstrap method, but I'd really like to see another
option that allows for out-of-band trust (based on ECDSA, probably).
It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones. The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them. JSON would be my preferred candidate.
Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON? That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).
Binary formats can be challenging to deal with and convert to other
formats. The experiences in the PKI world of ASN.1 have not been great, in
terms of interop. It tends to create islands and silos. This is probably
one of the reasons why X.509 and GPG are fragmented and why we dont really
have a widely deployed web of trust on the net. Another reason is simply
lack of developer resources to make tools. In that respect I think JSON
offers significant advantages, though I am interested in the security
issues raised.
On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen
gavinandre...@gmail.comwrote:
Spec updated: https://gist.github.com/4120476
Changes are:
Version numbers: a couple of people asked privately about adding
version numbers to the messages. In general, Protocol Buffers don't
need version numbers if later versions add only optional fields.
And best-practice is to know what version of something you're
expecting BEFORE you start parsing that something.
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
Following that best-practice of knowing what you're parsing before you
parse it, I added an invoice_version field to the SignedInvoice
message. It is now:
message SignedInvoice {
required bytes pki_data = 1;
required string pki_type = 2 [default = x509];
required bytes serialized_invoice = 3;
required uint32 invoice_version = 4 [default = 1];
required bytes signature = 5;
}
Handling of receiptURI errors:
Following discussion here, I changed the spec to say:
Clients may handle errors communicating with the receiptURI server
however they like, but should assume that if they cannot communicate
at all with the server then the Payment should either be retried later
or immediately rejected.
and under Receipt added:
The Bitcoin client must be prepared to handle the case of an evil
merchant that returns accepted=false but broadcasts the transactions
anyway.
I also added a TODO Test Vectors section with base64-encoded
examples of everything.
--
--
Gavin Andresen
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you
need to know about Bitcoins.
--
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel
projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
OK. I want to keep the signature field required, though, so how about: signature: digital signature over a protocol buffer serialized variation of the SignedPaymentRequest message where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data. Looks good to me. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Yet more comments (I guess at some point we need to stick a fork in it - or at least move on to implementing a prototype version). Maybe don't require the payment URI to be HTTPS. If you want to pay a Tor hidden service then HTTPS just adds unnecessary complexity. Just recommend to merchants that they use an encrypted connection and leave it at that. Though it's not strictly necessary, it'd be nice to have defined behavior for if you want to pay more than the requested amount, for a tip. Perhaps rather than zero value outputs will be ignored say, if some outputs have value and others don't, the user will be given the option of overpaying and the extra money will be split evenly between the zero valued outputs. That way a waitress can have the phone add a zero-valued output to her own wallet and that would prompt the wallet software to display some convenient UI for adding on 10% or whatever. receiptURI - receipt_url ? technically it has to be resolvable so uri isn't quite right. Display the proposed Outputs in as human-friendly a form as possible ??? Surely you'd just display the total amount requested? I don't think it ever makes sense to try and display outputs to the user directly. Re: the UI TODO - agreed but let's take it out of the BIP and maybe make it an alternative document. Or just replace it with a recommendation that the user interface should be designed to ensure users understand the difference between an unsigned and signed payment request, for best practices see here serialized_paymentrequest - serialized_payment_request? Otherwise languages that use CamelCase will look odd setSerializedPaymentrequest() The question of root CAs still needs resolution. I stick with my recommendation to support all CAs that browsers support. Obviously, it's better for a merchant to obtain an EV cert than a domain verification cert - the UI can reflect the higher level of verification. I doubt there's a need to specify a max number of certs in a chain. But if you want to, go for something high, like 256. There's no point in trying to put DoS mitigations into something like this, for the same reason HTML doesn't impose a maximum page size. It's in the message builders interest to ensure it gets read by all users. Crashing their clients doesn't achieve anything as long as the crash isn't exploitable. On Fri, Dec 7, 2012 at 11:45 AM, Mike Hearn m...@plan99.net wrote: OK. I want to keep the signature field required, though, so how about: signature: digital signature over a protocol buffer serialized variation of the SignedPaymentRequest message where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data. Looks good to me. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn m...@plan99.net wrote: Yet more comments (I guess at some point we need to stick a fork in it - or at least move on to implementing a prototype version). Yes, my next step is prototyping. Note that this is not a BIP yet: I want to have a working implementation before making this an Official BIP. Maybe don't require the payment URI to be HTTPS. Changed: receipt_url: Secure (usually https) location where... Though it's not strictly necessary, it'd be nice to have defined behavior for if you want to pay more than the requested amount, for a tip. yeah... I had similar thoughts on what to do if some Outputs specify an amount and others don't. I'm still waffling on whether or not I like allowing repeated Outputs; a single Output would make the spec a fair bit simpler, and if a merchant wants to split up a payment for some reason they could just generate another transaction. I want to move on to actually implementing this before creating complicated rules. Maybe the best way to tip a waitress is to get two separate PaymentRequests, one for the restaurant and one that goes directly to the waitress (depends on whether or not the restaurant needs or wants to know how much their employees are getting tipped, I suppose). Maybe it would be best to have a separate gratuity Output in the PaymentRequest. That's the kind of detail I think doesn't need to be worked out right now, I'd rather restaurants tell us what they need/want. Display the proposed Outputs in as human-friendly a form as possible ??? Surely you'd just display the total amount requested? I don't think it ever makes sense to try and display outputs to the user directly. This is the case of getting an UNSIGNED payment request; I've changed the wording a little to make that more clear. If a bitcoin client accepts unsigned payment requests (a couple of people have asked if that would be possible so I think that is desired), then it doesn't have the payer's identity-- all it has is the Outputs that will be paid. Re: the UI TODO - agreed but let's take it out of the BIP... Not a BIP yet serialized_paymentrequest - serialized_payment_request? Done. The question of root CAs still needs resolution. I stick with my recommendation to support all CAs that browsers support. I still like the idea of only including the root CAs who have jumped through the hoops needed to get the allowed to issue EV certs blessing. I'm not suggesting that all bitcoin merchants must get EV certs, but I am suggesting that they must get a certificate from one of the most reputable certificate authorities, and the ability to issue EV certificates is, I think, a good proxy for that. But, again: Not a BIP yet. Lets get something implemented and then hammer out details (implementing always turns up edge cases you forgot when spec'ing). -- -- Gavin Andresen -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
yeah... I had similar thoughts on what to do if some Outputs specify an amount and others don't. I'm still waffling on whether or not I like allowing repeated Outputs; a single Output would make the spec a fair bit simpler Yes, but at the cost of privacy. Generators of payment requests always have the option of just adding a single output and being done with it. But in future they'll probably want to keep their income in unlinkable chunks of a size that's up to them, and multi-outputs are needed for this (the idea being, the users wallet tries to keep a close-as-possible match between the requested outputs and their own). OK, let's punt on tipping for now. If a bitcoin client accepts unsigned payment requests (a couple of people have asked if that would be possible so I think that is desired), then it doesn't have the payer's identity-- all it has is the Outputs that will be paid. I see. If I were to implement a wallet I'd just display nothing (except the size of the request). Showing an address doesn't really help the user in any way. I still like the idea of only including the root CAs who have jumped through the hoops needed to get the allowed to issue EV certs blessing. The hoops only actually apply for EV certs though, they aren't required to do that verification for DV certs. The main reason to use the browser root CAs is that merchants are guaranteed to be able to re-use their existing certs. Otherwise they might have to buy new ones, which would be annoying. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Escrow/multisig is complicated enough to wait for another day. But certainly having a payment protocol is an important step towards it On 6 Dec 2012 07:32, Andreas Petersson andr...@petersson.at wrote: During/before the Payment Request there should be a method to exchange the public keys to be able to generate a common multisig address. Should this be handled in a different protocol, or be included in this spec? Or is there a method for the customer to verify that the specified BIP16 Output contains his address and the one from an escrow service? -- Andreas -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Spec updated yet again: https://gist.github.com/4120476 Renamed to PaymentRequest/PaymentACK. Added a 'network' field (main or test) to PaymentRequest so testnet and main network (and alterna-chain) payment requests don't get confused. Updated description of PaymentRequest.outputs: outputs: one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored). - RE: escrow/multisig: Setting up a multi-person escrow will, I think, need it's own set of messages. I think we should leave that for a future spec. Thumbnail sketch: escrow service or participant sends around an EscrowProposal, gets EscrowProposalACK's with public keys to use, then sends all participants an EscrowEstablished message with the final multisig script or address. Escrow gets funded by any/all of the participants, and then gets spent using the SignedPaymentRequest/Payment/PaymentACK protocol-- participants will pass around a SignedPaymentRequest and a partially-signed Payment message for all to approve. When I say pass around I'm not thinking of users copying and pasting, that would be a terrible user experience; all of that communication needs to happen automatically behind the scenes. Lets tackle that after we've got the simpler customer-pays-merchant flow working nicely (funded-escrow-pays-merchant is a subset of that, anyway). -- -- Gavin Andresen -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Re: the newest spec. Rather than make the signature over the
concatenation of, why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be ordered if you want,
even though all implementations should do that already.
Thumbnail sketch: escrow service or participant sends around an
EscrowProposal, gets EscrowProposalACK's with public keys to use, then sends
all participants an EscrowEstablished message with the final multisig script
or address.
Yeah, that sounds reasonable. Not that we should really design it now,
but let's use the term mediation rather than escrow, which has
connotations of depositing funds with the escrow service.
I think it's best to see the existing payment messages as structures
that'll get filled out with more features over time. So rather than
have a separate EscrowProposal message, you would integrate it with
payment requests. Older clients that don't understand mediation would
just ignore the extra data they don't recognize.
message PaymentRequest {
// One per mediator acceptable to the seller.
repeated MediationProposal mediation_data = 10;
}
message MediationProposal {
required SignedMediatorIdentity identity = 2;
// Opaque bytes that the mediator can be asked to turn into a human
readable description
// of how disputes will be mediated. The merchant sets this to
describe whatever policy it
// is willing to go along with, so policies may be arbitrarily complicated.
required bytes policy = 3;
}
message SignedMediatorIdentity {
required MediatorIdentity identity = 1;
// If the identity data is signed ...
optional string pki_type = 2;
optional bytes pki_data = 3;
optional bytes pki_signature = 4;
}
message MediatorIdentity {
// Name of the mediator to be displayed to the user.
required string friendly_name = 1;
// PNG image that can be used to represent the mediator to the user.
optional bytes logo = 2;
// Some text shown to the user under the name explaining the
mediators policies, why they should be chosen, etc.
optional string blurb = 3;
// An HTTP URL where a mediator can be reached to do things like
prove ownership of pubkeys, initiate the protocols, etc.
required string contact_url = 4;
}
... etc
So the user experience would be that when a payment request is received:
- older clients ignore the mediation_data field and do a direct
payment as normal
- newer clients ask the user to pick a mediator (if they want to) and
if mediation is requested, the PaymentRequest is then discarded and
the next step of the mediation protocol begins.
The old request has to be discarded because the outputs would have
been written on the assumption of no mediation being in use (for
backwards compatibility).
Anyway, though I'm awfully guilty, let's not get off track. Just that
this is how I imagined new payment features being done - as new
extensions to the payment protocol, which would be a living document
amended by BIPs.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen gavinandre...@gmail.comwrote: When I say pass around I'm not thinking of users copying and pasting, that would be a terrible user experience; all of that communication needs to happen automatically behind the scenes. Lets tackle that after we've got the simpler customer-pays-merchant flow working nicely (funded-escrow-pays-merchant is a subset of that, anyway). I think that the pass around method needs to happen in addition to the methods of transparent protocols that occur behind the scenes. For one, there's a lot of CONOPs that need to be worked out by getting knowledgeable people using it, and providing feedback about how it could/should/will be used and how it could be improved. The pass-around method is simpler to implement and still usable by the types of users that will be using it in the beginning -- experts. Also, I see that for very large, important multi-sig tx/contracts/escrow, the manual method might be preferred -- much the same way many people prefer manual-transmission cars even though automatics are easier -- some people/organizations will want the control. I'm all for protocols that enable higher-level access to this functionality, I'm just saying there should be lower-level access, too. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Dec 6, 2012 at 12:55 PM, Mike Hearn m...@plan99.net wrote: Re: the newest spec. Rather than make the signature over the concatenation of, why not just make it a signature over the serialized protobuf minus the signature field (as I did in my demo code). Otherwise it seems like we'd need more code than really necessary. We can state explicitly tags must be ordered if you want, even though all implementations should do that already. OK. I want to keep the signature field required, though, so how about: signature: digital signature over a protocol buffer serialized variation of the SignedPaymentRequest message where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data. -- -- Gavin Andresen -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
During/before the Payment Request there should be a method to exchange the public keys to be able to generate a common multisig address. Should this be handled in a different protocol, or be included in this spec? Or is there a method for the customer to verify that the specified BIP16 Output contains his address and the one from an escrow service? -- Andreas -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
I think that's OK. However, you should only be getting the version you
expect because when you request an invoice, your client should be
telling the merchant what protocol version you implement.
Does it make sense to have this spec not include the details of
bootstrapping? It's not complicated - we extend the URI spec in a
backwards compatible way:
bitcoin:1AbCdEfG?value=10.0label=Pay%20for%20Fooinvoice=https://merchant.com/inv/aB425az
When a compatible client sees the invoice param, it ignores the rest
of the URI and downloads the URL
https://merchant.com/inv/aB425az?ver=1.0
A server on merchant.com sees that the client expects a version 1.0
invoice and vends it. If ver=2.0 or whatever, it knows it can use 2.0
features. If extensions are supported, add new query params.
We should define a simple mechanism for extending the protocol now, so
people who want to make proprietary extensions don't conflict. The
simplest is to just say, if you want to add new fields to an Invoice
message, please update a wiki page with the tag numbers you're going
to use, and start from number X. Protobufs have a simple way to
formalize this in the language:
https://developers.google.com/protocol-buffers/docs/proto#extensions
message Invoice {
extensions 1000 to max;
}
The point of this is to allow you to define new parts of the messages
in separate .proto files. It's only a minor convenience but it means
if you want to use, say, two extensions that weren't yet folded into
the main spec, you can more easily do so without having to do a manual
merge of the message definitions together.
For instance, if you wanted to extend the protocol to support
specification of recurring billing, you could make a file called
recurring-invoices.proto containing:
message Recurrences {
required uint32 every_seconds = 1;
optional uint32 start_time = 2;
}
extend Invoice {
optional Recurrences recurrences = 1005;
}
then you update the wiki page to claim tag number 1005 and apps can
easily use your new features. If/when the feature gets standardized
via a BIP, the core .proto definition can be extended to include these
messages and the extensions can go away.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
The thing that bugged me most about the original spec was the sole reliance
on X.509 - glad to see you've made that optional. I think many people will
balk at deferring our identity trust to the existing CA's. I think it's a
fine bootstrap method, but I'd really like to see another option that
allows for out-of-band trust (based on ECDSA, probably).
It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones. The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them. JSON would be my preferred candidate.
Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON? That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).
On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen gavinandre...@gmail.comwrote:
Spec updated: https://gist.github.com/4120476
Changes are:
Version numbers: a couple of people asked privately about adding
version numbers to the messages. In general, Protocol Buffers don't
need version numbers if later versions add only optional fields.
And best-practice is to know what version of something you're
expecting BEFORE you start parsing that something.
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
Following that best-practice of knowing what you're parsing before you
parse it, I added an invoice_version field to the SignedInvoice
message. It is now:
message SignedInvoice {
required bytes pki_data = 1;
required string pki_type = 2 [default = x509];
required bytes serialized_invoice = 3;
required uint32 invoice_version = 4 [default = 1];
required bytes signature = 5;
}
Handling of receiptURI errors:
Following discussion here, I changed the spec to say:
Clients may handle errors communicating with the receiptURI server
however they like, but should assume that if they cannot communicate
at all with the server then the Payment should either be retried later
or immediately rejected.
and under Receipt added:
The Bitcoin client must be prepared to handle the case of an evil
merchant that returns accepted=false but broadcasts the transactions
anyway.
I also added a TODO Test Vectors section with base64-encoded
examples of everything.
--
--
Gavin Andresen
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you need
to know about Bitcoins.
--
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss m...@coinlab.com wrote:
Why don't we sign the text representation of a (utf8) JSON, rather than some
complex encoding standard of JSON?
Because the results from standard JSON parsers are undefined if I give
you an envelope JSON that has repeated keys.
For example:
{
pki_data : ...hex-or-base64-encoded certificate chain...,
signature : hex-or-base64-encoded-signature-bytes,
message : string-encoded-utf8-JSON,
message : another string-encoded-utf8-JSON,
signature : more hex-or-base64-encoded-signature-bytes,
pki_data : ...another certificate chain...,
}
The JSON spec doesn't say what you'll get when you decode that mess.
Maybe the first instance of each field, maybe the last, maybe one
picked at random...
The JOSE (Javascript Signing and Encryption) spec says Thou Shalt Use
A JSON Parser That Treats Multi-defined-keys As An Error.
I expect that most developers will be lazy and will just use whatever
JSON parser is convenient, no matter how much the spec/documentation
warns them not to. And that makes me nervous, because I can imagine
attackers taking advantage of mismatches between (say) the JSON
parsing software used by some back-end server process and a front-end
JavaScript web wallet UI.
--
--
Gavin Andresen
--
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote: 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement where users pay fees, getting transactions into the chain has a cost. In cases where you trust the sender to not double spend on you, you may keep a fee-less transaction around in your pocket. Then when it's your turn to pay, you use some unconfirmed transactions to do so. This brings up an additional point. If we're mutually trusting parties (or secured by some kind of external mechanism), and you've given me a payment which I haven't broadcast for confirmation— and later we make another transactions I should be able to offer you the original unconfirmed txn and ask if you'd instead be willing to write a replacement that combines both payments. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote: Witness the absurd design of SMTP that means you can't start a paragraph with the word From because that's a new-message marker! Actually that has absolutely nothing to do with SMTP. It's down to the file format of the standard BSD UNIX mailbox (which uses lines beginning with 'From ' to delimit messages). roy -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote: You shouldn't need to escape and unescape data that is not being interpreted in any way. Funilly enough pretty much all low-level links that make up the Internet use either bit-stuffing or byte-stuffing to escape a particular bit sequence or byte that terminates an HDLC frame. I'm not particularly agreeing or disagreeing with you on the suitability for the case at hand, but as an absolute your statement doesn't hold water. The use of a terminator for a variable-length data structure rather than a length prefix is a design desicion that has little-to-nothing to do with the debate of text-versus-binary. Anyone remember Holerith constants? roy -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Spec updated: https://gist.github.com/4120476
Changes are:
Version numbers: a couple of people asked privately about adding
version numbers to the messages. In general, Protocol Buffers don't
need version numbers if later versions add only optional fields.
And best-practice is to know what version of something you're
expecting BEFORE you start parsing that something.
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
Following that best-practice of knowing what you're parsing before you
parse it, I added an invoice_version field to the SignedInvoice
message. It is now:
message SignedInvoice {
required bytes pki_data = 1;
required string pki_type = 2 [default = x509];
required bytes serialized_invoice = 3;
required uint32 invoice_version = 4 [default = 1];
required bytes signature = 5;
}
Handling of receiptURI errors:
Following discussion here, I changed the spec to say:
Clients may handle errors communicating with the receiptURI server
however they like, but should assume that if they cannot communicate
at all with the server then the Payment should either be retried later
or immediately rejected.
and under Receipt added:
The Bitcoin client must be prepared to handle the case of an evil
merchant that returns accepted=false but broadcasts the transactions
anyway.
I also added a TODO Test Vectors section with base64-encoded
examples of everything.
--
--
Gavin Andresen
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Hi, not sure if you already noticed, but I and my friends are actively working on bitcoin hardware wallet. This should be pocket size device with something like 256kB flash and 80 MHz CPU, talking with the computer over USB. User will prepare transaction on the machine, send it to the device, device shows target address on the display and user confirms it by pressing the button. We're trying to make bitcoin payments safe even on hacked computer. For this reason we're also implementing SPV so device don't need to trust computer with any kind of information. The biggest existing problem is that user cannot be sure that the address displayed on computer screen is correct and he's confirming valid address. I don't have any solution for this problem yet. I just appreciate an activity in payment protocol area, because it can (with some care) solve this problem and my appeal si to keep all this simple. I'd be very happy with simple payment protocol which can be implemented even on devices like I'm working on, so device with few widely used certificates stored in the memory will be able to display origin of the invoice and confirm its validity. slush On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd w...@uchicago.edu wrote: After doing more thinking, what about letting a spend sign more information associated with the transaction, such as a transaction ID provided by the merchant? This seems to solve a lot of the problems being put forward, with much less complexity. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: Roy Badami's comments on edge cases around submitting a Payment message to a merchant and then not receiving a timely response: I agree, it is messy. I'm hesitant to try to specify One True Way of handling it in the spec; I've got a feeling that this might be a place where different implementations might try different things, with the best implementation winning. For example, if some future nifty-keen Bitcoin client is re-using an old Invoice to send a monthly subscription payment and they can't contact the paymentURI, then the right thing is probably for it to retry once a day for three or four days and if they all fail then give up and tell the user that the service is no longer in business (or changed their paymentURI without leaving behind a redirect). If it has a single-use Invoice created a minute or two ago, the right logic might be: + If the paymentURI is completely non-responsive, just error and tell the user payment failed + If connected to the paymentURI and payment sent, but disconnected before receiving a response, then try to send-to-self the coins to cancel payment. Again, I'm not at all sure that is the best way to handle it; implementors have the right incentives to give their users the best user experience, so I feel comfortable leaving the spec fuzzy for now. -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
I'd still like to understand the rationale for having the merchant broadcast the transaction - it seems to add complexity and create edge cases. How about this as an alternative proposal: The buyer's client prepares the transaction and computes its txid. It then sends a ValidatePurchase message to the merchant containing the proposed Outputs and a copy of the merchant_data along with the txid. Assuming the proposed payment is accepted as valid by the merchant, the buyer's client simply broadcasts the pre-prepared transaction in the normal way, and it is the merchant's responsibility to watch for this transaction to arrive over the p2p network/blockchain to complete the purchase. (So if the merchant rejects the purchase at the ValidatePurchase stage, they never get to see the transaction that the buyer prepared, and there's therefore no need for a send-to-self to cancel it.) An optional RequestReceipt message (perhaps containing the merchant_data and txid) can be sent by the client after the transaction has been broadcast - but by making this explicitly optional it forces the merchant to rely on seeing the bitcoin transaction to 'commit' the payment and not on the RequestReceipt message. As far as I can see this proposal has no edge cases where the buyer and merchant have differing ideas as to whether the transaction has 'comitted' - or at least, no more edge cases than the standard bitcoin protocol has. roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
I'd still like to understand the rationale for having the merchant broadcast the transaction There are several reasons for this: 1) P2P network sockets are a limited resource and bringing up connections to the network, whilst somewhat fast today, is not guaranteed to be fast in future. Passing transactions to the merchant for broadcast reduces the load on the P2P nodes because lots of thin clients aren't any longer connecting and disconnecting when sending. They only need to talk to the network when the user has received money. 2) Some users may not have network connectivity at all. For example, this happens quite often whilst traveling at Bitcoin conferences ;) The solution, which Andreas and I prototyped in Berlin together, is for the buyer to communicate only with the seller which can be done over Bluetooth or WiFi Direct or some other mobile radio protocol. Again, send only, but for the common case where you load up your wallet before setting out and then buy things, it works OK. 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement where users pay fees, getting transactions into the chain has a cost. In cases where you trust the sender to not double spend on you, you may keep a fee-less transaction around in your pocket. Then when it's your turn to pay, you use some unconfirmed transactions to do so. People pass around longer and longer chains of un-broadcast transactions until a payment crosses a trust boundary, at which point the receiver adds on their own transaction that spends back to himself but with a fee, and broadcasts them all together as a unit. In this way only people who genuinely need to fear double spends pay for security. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote: I'd still like to understand the rationale for having the merchant broadcast the transaction There are several reasons for this: [snip] All good reasons, thanks for the explanation. Though I still like my idea of a ValidatePurchase message that allows a buyer to ask a merchant would you accept this payment? without actually supplying a signed transaction. Make it optional if you care about minimising the number of round trips, e.g. for fast NFC payments. Having such a message reduces the extent to which you need to trust the merchant not to spend a transaction that they've rejected. (And in the non-Internet connected case this is particularly useful since the client won't have the ability to broadcast a pay-to-self transaction.) roy -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: the ifex-project and other electronic invoicing standards: Thanks for the pointers, Walter! I'm all for adopting the best ideas that have come before, as long as we end up with something useful and small enough to convince ourselves it is as secure as we can make it. Fair enough, although I would posit: 0. You can't get more secure than not doing it at all. 1. Small is sometimes beautiful, but sometimes just the 999th crippled and half-featured attempt at a nontrivial problem space (...linked heavily to implementation-time assumptions and/or specific peer systems, and by its very nature destined for the dustbin of time? Well, maybe. Eventually, we all are.) 2. X.509 is not small (or beautiful, unless one is some weird new kind of centralized cryptographic trust fetishist, of some sort you might see with furrowed brows, boozing at midday sporting key anchor tattoos in old convention polo-shirts, mumbling to themselves about the employee-motivation benefits of single sign-on...) looked at the ifex spec, and quickly got lost. It would help me if you could write up what our motivating use cases would look like if implemented on top of ifex. Yes. Understandable. Thoughts around an IFEX protocol proposal, unlike the other proposals, are still drafty (err...as a coastal verandah?) and not the clearest. However, we have much research and progress has been achieved in the odd year-or-so since beginning. The fundamental concerns of such a protocol (regarding the establishment of neutral, open and technically-viable proposals for internet-wide currency/commodity, market and financial endpoint identification) have already been reasonably met. This has opened the door to the potential for faster progress on the IFEX protocol itself (a mechanism for the identification, negotiation, description, execution and management of financial transactions over their lifetime), like, right about now. Which is kind of the same zone of potential functionality (at least in a naive, linguistic comparison sense) that people are talking about here. Because of the hope to garner more interest from the Bitcoin community with this post (do read on!), I spent a bunch of hours today cleaning up and converting the IFEX Protocol's current breezy-draft form back from the wiki formatting it had been lazing and grazing (and growing, albeit slowly) in for the greater part of the year and moving to Github (forks and issues very much encouraged) over here: https://github.com/globalcitizen/ifex-protocol (Discussion list at http://group.ifex-project.org/ actually has quite a few members at present, despite appearances to the contrary) implemented on top of ifex. Re: implemented on top of ifex, this is kind of opposite to how IFEX works. IFEX's idea is to provide a flexible yet stable protocol that lets individual (potential, ongoing, or completed) transactions on arbitrary (legacy, conventional, emerging, or future) settlement systems (in arbitrary currencies/commodities) to be described and facilitated (executed, routed, monitored, etc.) in real time, by describing accurately the objective properties of each of those systems and components. So, for example, an end user, requiring a transfer of x of y currency/commodity from 'point a' to 'point b' would find routes to achieve that, evaluate them in terms of monetary and temporal overheads against their own trust and risk models plus any legal, privacy or other requirements in order to select and effect the most appropriate manner of settlement. In short, IFEX sees Bitcoin as having such-and-such properties, matches that to a need to transfer some funds, and effects the transfer, monitoring and/or reporting on its state in a normalized fashion throughout its lifetime. I'll try again to describe the motivating use case: == Recognising that Bitcoin is not the only emerging financial community or settlement system facing real world business integration challenges, and recognising the significant complexity of these in common situations (multi-hop transactions, arbitrary currency transactions, foreign exchange automation, liquidity guarantee challenges, settlement latency negotiation, invoicing periods, commercial payment or shipping terms, sovereign (exchange rate fluctuation) and other forms of risk management, potentially simultaneous multi-level fee, tax and discount requirements, product/service coding, line items, complex tax calculations (particularly in the US, and which may be based on both buyer and seller geolocation), legal requirements to include various metadata, etc.), instead of investing valuable developer time on internal implementation (and subsequent maintenance) of a tightly-scoped (==crippled?) business-level protocol extension to Bitcoin that can be perhaps fairly characterised as unlikely to quickly evolve to meet many of these real world requirements, and with as yet unclear real world demand for such from the Bitcoin community, who must
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Wed, Nov 28, 2012 at 11:43:19AM +0100, Mike Hearn wrote: Peter is correct that there are a few degrees of freedom in protobuf serialization, though far fewer than with JSON. FWIW I re-read the specs again and turns out my memory was wrong. (I last looked at this about four months ago) Duplicated fields are handled in a defined manner, with the last field seen in the serialization being the one whose value is used. Again, repeated fields are treated as elements of a list, preserving order. It does raise the interesting question do the implementations that don't preserve order of unknown fields, preserve the order of multiple unknown fields, either repeated or not? I'd like to think upstream would be open to resolving these ambiguities. I gotta admit, I suspect they won't be that open. Protocol buffers was designed because Google needed a fast serialization method suitable for many different internal projects. Needing round-trip idempotence seems like a rare requirement to me, especially for internal use. Re-serialization of an Invoice message in the Payment message is a potential source of mistakes. There's no need to ever concatenate these messages and alternative implementations that don't order serialized fields by tag number are missing an important optimization, so they could be fixed. The main issue is treatment of unknown fields. If/when the Invoice message is extended with other fields that are round-tripped through an old client, the data may get lost. JSON doesn't help resolve that either, of course. There are a few solutions: Well, actually you can take advantage of the message concatination ability of protocol buffers to extend a message by simply appending the new fields to the existing thus either defining new fields, or overriding old values as required. If you want to de-duplicate though you run into the problem all over again. On the other hand JSON handles this case fine too provided that your JSON implementation supports dictionary objects with arbitrary fields. Just use the object as is and the unknown fields will be re-serialized properly at the other end. Some implementations will have to be careful to handle collisions with existing keys in the namespace. (consider in Python what would happen if you mapped your object to a class instance, and the serialization included the key __init__) That said, JSON is quite problematic with numbers. For instance, you have to be careful to keep integers represented as pure integers below what Javascript can handle, the maximum integer exactly representable in a double float, or the JSON won't be parsable in Javascript even if many other languages handle it fine. Protocol buffers is at least pretty explicit about what size integers are. 1) Change the type of the Invoice field in Payment to be bytes and set it to be the hash of the originally received binary Invoice message. Downside, requires merchants to track all outstanding invoices. 2) Ask protobufs upstream to modify the spec/implementations so ordering of unknown fields is specified. The Python implementation could be extended to support them so Python implementors don't end up with accidental message downgrades. 3) Language of the spec could be changed to explicitly state that the received Invoice may not be binary-identical to the one that was sent, in the case of a client that incorrectly downgrades the message. Thus you'd be expected to check what the Invoice was using merchant_data which is opaque and could just be, eg, a database key on your own end. 4) Instead of submitting the entire Invoice back to the merchant, just the merchant_data could be in the Payment message. Of the four options I prefer the last. What is the use case for resubmitting the entire invoice anyway? Even if protobufs are improved Note that I think the SignedInvoice message itself is broken, because protobuf implementations have no reason to guarantee that they can give you the serialized bytes of the Invoice sub-message. It's a quite specific use-case that isn't needed for pretty much anything but crypto. FWIW I took a quick look at the official API's, C++, Java and Python, and as far as I can tell none of them support accessing the binary serialization of a message field other than by re-serializing the message. Really the invoice field should be declared as bytes serialized_invoice, as inconvenient as that is to work with. so handling of round-tripping new messages through old [Python] clients is more rigorous, some implementors will probably convert the protobuf objects into some internal forms for whatever reason (or serialize them to a database, etc) and they're very likely to mess up the handling of unknown fields when they do it. Since the Payment message includes an *untrusted* Invoice that the vendor needs to authenticate the whole invoice no matter what on Payment reception. In many cases that implies they have to keep some sort of database of quotes
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
RE: Changing SignedInvoice's invoice field to 'bytes serialized_invoice': Good Idea, I agree it will avoid potential issues. I think it then makes sense to pull the pki_type and pki_data into SignedInvoice, too, and specify that the signature is on the SHA256-HMAC of pki_type, pki_data, and serialized_invoice (being careful to combine them in a way that is secure). RE: Changing Payment to include just merchant_data and not the entire Invoice: Agreed, good idea. RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand Unified Solution: No, we have problems that need a solution right now. And, having written one (I was the lead author of the ISO/IEC 14772-1 international standard) I'm very pessimistic about your chances for anything like IFEX to actually be adopted. -- -- Gavin Andresen -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
After doing more thinking, what about letting a spend sign more information associated with the transaction, such as a transaction ID provided by the merchant? This seems to solve a lot of the problems being put forward, with much less complexity. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Short comments: * What if the SignedReceipt is not received AND the transactions IS posted on the p2p. Then you have payed for the goods, but you don't have a receipt. This could happen both from malice or system failures. ** Suggestion - sign the invoice with the key to which to send the transaction, the proof of payment, equivalent to a signed receipt is then in the blockchain. This scheme would work both with or without x509, if you want to include x509, the message in the invoice could simply be signed by the x509 certificate as well. PRO: Any user can send signed invoices, not only those with a x509 cert. PRO: No limbo situation with no SignedReceipt CON: This disables the use of anything but payment to key/address incl multisig etc. However, the wast majority of use will anyway be payment to key/address. Support of general pay to script could be supported through the payment scheme proposed earlier by Mike: No non-fee payments are accepted, except in a group - i.e. it is up to the merchant to generate the final transaction incl the fees, and that one could be to a general script. This also keeps the support of pay to general script needed for a client to a minimum. Cheers, Michael -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager grona...@ceptacle.com wrote: * What if the SignedReceipt is not received AND the transactions IS posted on the p2p. I think this is a problem with confusing terminology rather then the spec itself. The original formulation had a receipt being something generated purely by the buyer. The signed Invoice message + the Bitcoin transactions paying to the outputs + the merkle branches showing acceptance by the network *is* the receipt. The SignedReceipt message is useful in the sense that it shows confirmation by the merchant, but if you don't get one, you can still prove you paid the invoice. So from this perspective perhaps SignedReceipt should be renamed to Acceptance or something like that, and then the spec should call out that a signed invoice plus accepted Bitcoin transactions is mathematically a proof of purchase. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
The SignedReceipt message is useful in the sense that it shows confirmation by the merchant, but if you don't get one, you can still prove you paid the invoice. So from this perspective perhaps SignedReceipt should be renamed to Acceptance or something like that, and then the spec should call out that a signed invoice plus accepted Bitcoin transactions is mathematically a proof of purchase. Which is why I find the SignedReceipt somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway. Further, the inclusion of x509 is not really needed in the spec - you don't need to sign the invoice with an x509, you can use the payment key. The proof would still be equally binding, and valid also for non holders of x509 (server) certificates (like normal people). Finally, host certificates does not normally keep in their purpose S/MIME Signing. So you are bending the intended use of the x509 certificate anyway. /M -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
If a merchant/payment processor is willing to take the risk of zero or low confirmation transactions (because they are insured against it, for example), they were allowed to reply accepted immediately, and this would be a permanent proof of payment, even if the actual Bitcoin transaction that backs it gets reverted. I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn't get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...) So the SignedReceipt is legally not worth the bits it is composed of, hence I don't see the point in supporting it. If you are selling atoms you can usually wait for N confirmations (even though you start shipping I guess you can recall a parcel within 144 blocks). If you are selling bits (like access to a site), you can revoke that access once you discover the transaction did not go through. So I can't find a use case where a Signed Receipt in the proposed form is advantageous. /M -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
One more thought: RE: Receipt verus Acceptance : I believe Receipt is the right term-- it means I got your payment, NOT your payment has cleared. E.g. if I hand a merchant a paper check they'll hand me a receipt, but the check could still bounce. That's the analogy here-- a merchant might give you a receipt, but if the transaction is rejected by the network for whatever reason (Finney attack maybe) you cannot expect to go to court with your invoice/receipt and claim you made a valid payment. -- -- Gavin Andresen -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:
x509chain: one or more DER-encoded X.509 certificates that identifies
the merchant. See the Certificates section below for details.
Personally, I'd like to see fewer implicit ties to X509. With X509 as one
option. For example, I'd much prefer to see a doorway to the future left open
like this:
message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;
or similar, instead of x509chain.
In particular two additional identification types:
- GnuPG (obviously)
- Hash based
The hash-based system would be there as a method of leveraging an existing
trusted connection, without needing to get into the nitty-gritty of
certificates. For example, I am paying for something on a web site; I
presumably already have a secure connection that I trust to that site. That
site can issue me an invoice (which is to be sent to the bitcoin client) _and_
a hash of the certificate on the same page.
I trust that hash because I received it over a secure connection from a
trusted source. When my bitcoin client pops up with the received invoice, it
shows me the hash of the invoice, and I can be sure that it is from the web
site I thought it was from.
Imagine I'm a (very) small business, I have two or three customers. I want to
email one of my customers an invoice. I don't want to have to get an X509
certificate, and I don't necessarily know how. However, I can ring my
customer up and say I've generated an invoice with my bitcoin client, it is
hashed A7DE-521X-9977. Write that down and confirm it when you get my
invoice. Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
That hash would then be reported via some secure channel outside of bitcoin's domain. OK, I see. I guess that could be a reasonable fallback for the case where you have a secure channel. I don't understand what the relevance of multi-factor is to invoices? Yes, exactly. It's about paying who you think you're paying (when you confirm on a second uncompromised device). -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote: On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has, otherwise your invoice would appear in the UI as unverified and is subject to manipulation by viruses, etc. That's expected behaviour - except it's mainly be manipulated by *users*, not viruses (which can just as easily manipulate whatever custom cert store we use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no matter who Joe is or what connections he has. So using the OS cert store would effectively restrict merchants to the intersection of what ships in all the operating systems their users use, which could be unnecessarily restrictive. As far as I know, every browser has its own cert store for that reason. Browsers with this bug are not relevant IMO. This is messy. It's important to people to know that their cert will be accepted by ~everyone because non-acceptance looks like malice. If the cert system is actually to provide value then false positives need to be low enough that people can start calling in law enforcement, computer investigators, etc.. every time a cert failure happens. Otherwise there is little incentive for an attacker to not _try_. Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. Would you find it acceptable if something supported a static whitelist plus a OS provided list minus a user configured blacklist and the ability for sophisticated users to disable the whitelist? This way people could trust that if their cert is signed via one on the whitelist they'll work for ALL normal users.. and the UI can have very strong behavior that protects people (e.g. no 'click here to disable all security because tldr' button)... but advanced users who can deal with sorting out failure can still have complete control including OS based control. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client had their own list, you'd be back to the original problem of not being sure your CA is on all lists. Would you find it acceptable if something supported a static whitelist plus a OS provided list minus a user configured blacklist and the ability for sophisticated users to disable the whitelist? How is this whitelist any different from the list of CAs included by default with every OS? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen gavinandre...@gmail.com wrote: This is the next big lets all agree to do things the same way thing I think we should tackle. I'm particularly looking for feedback from other bitcoin client developers, even if it is just a quick looks reasonable, if everybody else is going to do it then I will (eventually) too... Comments: 1) Payment message should include ability to specify the transaction _or_ a transaction id sent via normal means over the network. 2) I think a significant bitcoin userbase will want to operate outside the full root-CA chain. Just look at https:// websites now. Self-signed certs are quite common, because it is easier, while being more secure than http:// So some provision for self-signed certs, a use case in wide use elsewhere, or equivalent thereof, seems reasonable. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for which has more overlap with the discussion here? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? Of the three currently published proposals, all are essentially IANA registry proposals. We are currently working with IETF staff, with open offers of support from multiple well funded commercial bodies, to transition these proposals through to IANA management. It appears that the Independent Stream Editor path will be used to transition these through to IANA, at which time the proposals themselves will be converted to Informational status. (As far as I understand right now, Within the IETF, Standards Track has special meaning and entails relatively large degrees of bureaucracy that are not within the current contributors' resources. It is also worth pointing out that many popular protocols implemented on the majority of systems (IIRC, such as IMAP) never reach formal standardization for this reason. It should be noted that in these cases, this does not make the protocols any less attractive as potential components for system implementation.) It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for which has more overlap with the discussion here? As outlined in the previous post: - Internet Financial EXchange (IFEX). A proposal under development that facilitates the negotiation of financial transactions between internet-based financial endpoints. (The area we would love your input) http://www.ifex-project.org/our-proposals/ifex As well as the information linked to above, significant but not particularly well grounded discussions have occurred regarding the IFEX-based paradigm for settlement versus some other proposed paradigms, in particular Ripple (as it appeared some months ago), which can be read here: https://groups.google.com/forum/?fromgroups#!topic/rippleusers/v4bEBZZVEsA[1-25] Kind regards and with the hopes of combining our efforts as a joint proposal that can benefit other currencies/commodities and settlement systems as well as Bitcoin, Walter Stanish Skype:walter.stanish -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? Of the three currently published proposals, all are essentially IANA registry proposals. We are currently working with IETF staff, with open offers of support from multiple well funded commercial bodies, to transition these proposals through to IANA management. I hate to inform you that you have been mislead. The IETF and the IANA do not operate as you outlined above. Having spent too many years within ICANN/IETF/IANA I can assure you are mistaken. Your drafts are expired and it appears that there is no support for a finance working group in the IETF. -rick -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
We are not establishing an IETF working group, which is an option that was explored prior to the Paris meeting and has been sidelined at present for depth-of-bureaucracy by the backing commercial entities. Rather, we are establishing a top-level IANA registry group. This is not anticipated by the IETF old-guard working with us to be either (a) controversial or (b) possible to block. My last note in this sub-thread. Mine too! There are no IANA registry groups, there is no such thing, and no way to form one. Reading between the lines, I believe this phrase, which is not my own but that of experienced IETF staff, refers to the groups visible at http://www.iana.org/protocols/ (which you yourself cited). Whether it is formally used or not is unknown to me. The IETF can ask the IANA to form a registry but these things take lots of support and take a long time, Expert opinion estimates six weeks, and by current estimates, we should have an arrival circa February. and these are only created through standards track RFC. ICANN runs the IANA and there is no such framework that you elude to. Review http://www.iana.org/protocols/ I would like to suggest that perhaps exactly this sort of banter is an excellent illustration for the Bitcoin community of what we have been up against in this (conceivable simple an public benefit oriented) endeavour. If you also look at the fact that the ISO4217 registry (to take currency/commodity codes as just one example) there is apparently not even a public list of requirements for codepoint issue. This sort of thing is *exactly* why the internet community appears to desperately need an open registry - allowing public internet bodies (IANA) to function to support innovation and interconnectivity for all sectors of the internet's various financial communities so that anyone, including innovators, can obtain interoperability via simple, hassle-free paths, without encountering self-important bureaucrats. We anticipate victory circa February. - Walter -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
