Spec updated: https://gist.github.com/4120476
Notable changes are:
+ Removed SignedReceipt
+ Replaced Invoice.x509chain with a "pki_type" and "pki_data" to make
using other identity systems cleaner.
+ Added a "Why not an existing electronic invoice standard?" section
to the design notes
--
--
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
Source code URL: https://github.com/jgarzik/picocoin/
I'd like to announce another bitcoin implementation, which is really
two useful pieces in one:
libccoin - a bitcoin library, written in C
picocoin - A lightweight, C-based SPV bitcoin wallet client
libccoin supports all key network
> 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 w
On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:
> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce a
> Personally, I'd like to see fewer implicit ties to X509. With X509 as one
> option.
That's pretty much what we have today - in future other schemes can be
proposed as extensions. Protocol buffers are easily extended, they
ignore unknown fields. Then you'd wait and see what the invoice
request l
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
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 mi
RE: SignedReceipt: I agree it is superfluous. I'll remove it from the spec.
RE: "it is controversial use of the host key to use it for digital
signing of documents" : The idea of embedding a x509 certificate
chain comes from the IETF's JSON Object Signing and Encryption working
group "JWS" spe
> No, the point of using X509 certs is to get a verified identity (a
> domain name) on the receipt, this is needed for multi-factor
> authentication. You can't do that without some kind of third party
> asserting to an identity.
Agree that you need a third party to verify identity. But the verifi
> 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.
No, the point of using X509 certs is to get a verified identity (a
domain name) on the receipt, this is needed for multi-factor
authentication. You c
>
> 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
> transac
On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote:
> >
> > 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 shou
>
> 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 shou
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager 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
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 transa
Luke-Jr - common subset of what operating systems ship is fine for me
as long as people do due diligence around mobile OS' here. It seems
easier to me to just grab a list from a popular browser, on the
grounds that SSL is mostly used by them so nobody is going to buy an
SSL cert rejected by IE/Fire
17 matches
Mail list logo
