Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Gavin Andresen
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Andy Parkins
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
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

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-11-27 Thread Pieter Wuille
On Wed, Nov 21, 2012 at 01:38:37PM -0500, Matt Corallo wrote: On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote: On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote: I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt.