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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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.
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
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 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
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
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,
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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 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,
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
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 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
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
48 matches
Mail list logo
