Alan Reiner gmail.com> writes:
>
>
>
> On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen
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.
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 thr
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
The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured. And the great thing is that it's easy to do and you don't
need
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn 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
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 m
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
s
On Mon, Dec 17, 2012 at 6:23 AM, Melvin Carvalho
wrote:
> 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 R
On 17 December 2012 10:19, Mike Hearn 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, pleas
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 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
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
On 17 December 2012 03:18, Jeff Garzik wrote:
> On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
> wrote:
> > On 3 December 2012 20:35, Mike Koss wrote:
> >> It would also be really nice to migrate to textual representations of
> data
> >> structures as opposed to binary ones. The most success
On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
wrote:
> On 3 December 2012 20:35, Mike Koss 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 tha
On 3 December 2012 20:35, Mike Koss 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 meth
> 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 alw
On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn 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
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
> 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 buffe
On Thu, Dec 6, 2012 at 12:55 PM, Mike Hearn 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 co
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen 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 c
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 b
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:
output
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" wrote:
> During/before the Payment Request there should be a method to exchange
> the public keys to be able to generate
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 co
I've had some push-back on the names of the proposed messages-- e.g.
"Invoice" in the accounting world means "I've already given you a
product or service, here is what you owe, payment terms, what forms of
payment are accepted, etc."
I think there might also be confusion about why we're defining o
> 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,
On Mon, Dec 3, 2012 at 5:26 PM, Roy Badami wrote:
> 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 w
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 seq
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
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn 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
> 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.
There are lots of successful binary protocols: TCP, IP, PNG, JPEG,
MP3, DNS, SSH, SSL, the Bitcoin protocol itself. What
On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss 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:
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
al
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 vers
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 Validate
> 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. Passin
On Thu, Nov 29, 2012 at 12:07 PM, Roy Badami wrote:
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction - it seems to add complexity and create edge
> cases.
Mike Hearn has experimented with in-person payments using
bluetooth/NFC on a phone, where the
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
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
implement
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,
devi
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.
---
> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in
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 serial
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) Dupli
> 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, alth
The current spec is ambiguous in the case of what to do if the invoice
contains one output of a fixed amount and one or more outputs of an
unspecified amount. Should the user be prompted once per output? That
seems suboptimal. Prompted once for a value that's then randomly
distributed between all o
On Mon, Nov 26, 2012 at 05:37:31PM -0500, Gavin Andresen wrote:
> Why not JSON?
> -
>
> Invoice, Payment and Receipt messages could all be JSON-encoded. And
> the Javascript Object Signing and Encryption (JOSE) working group at
> the IETF has a draft specification for signing JSON data
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
--
--
> 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
>> 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 antic
>
> 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 anticipa
>> 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. Ha
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish 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 wit
>> 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
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish 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 ove
> 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..."
I
Supporting DNSSEC/DANE in the future when they are widely deployed is a great
idea.
Note that the x509chain field is 'repeated', and any repeated field may have
zero entries. So I would suggest supporting other PKI systems in the future by
adding optional new fields (for maximum compatibility o
On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn wrote:
>> Perhaps we should agree to talk about everything _except_ that first?
>
> Yeah, alternatives to X.509 chains don't interest me right now except
> in the sense that they should be cleanly implementable with future
> extensions.
>
> So if you car
On Tuesday, November 27, 2012 12:16:07 AM Gregory Maxwell wrote:
> On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> >> Would you find it acceptable if something supported a static whitelist
> >> plus a OS provided list minus a us
On Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr wrote:
> On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
>> Another nifty thing is that it can associate a cert to a domain and a
>> payment address, if one were to put said address in the DNS :)
>>
>> Now I am sure the majority of the bitcoin
On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
> Another nifty thing is that it can associate a cert to a domain and a
> payment address, if one were to put said address in the DNS :)
>
> Now I am sure the majority of the bitcoin user-base desires anonymity,
> but as a merchant I wou
> Perhaps we should agree to talk about everything _except_ that first?
Yeah, alternatives to X.509 chains don't interest me right now except
in the sense that they should be cleanly implementable with future
extensions.
So if you care about DANE or DNSSEC or custom PKI infrastructures or
whateve
On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> 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
I hope you all take a moment to see what DANE leverages with DNSSEC
and SelfSigned x.509 certs. DANE provides the capability for any
entity to associate a self signed certificate with a domain name. This
capability removes the critical path of whitelists and/or Root CA
certs.
Another nifty thing i
X.509 has some problems we have recent experience with. I'd prefer to
leverage something like DANE which looks to help with assertions
around certificates and creates an option around the CAs and x.509
roots.
-rick
On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:
> This is the next big "l
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen 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
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
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr 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 you
> 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).
The point of using signed invoices as virus protection isn't to change
what the user sees on the infected host. The point is the invo
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 i
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.
So using the OS cert st
On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote:
> Minor caveat, IMHO we should support all CAs used by the popular
> browsers.
I would prefer using the user-accepted certs at the operating system level...
--
Mo
Obviously this LGTM :)
Minor caveat, IMHO we should support all CAs used by the popular
browsers. This ensures no merchant ever finds that their SSL cert they
already own is OK for the web but not for Bitcoin. I don't see a need
to be stricter here, given all it achieves is signing some data in a
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 P
87 matches
Mail list logo
