That's fine. I just want to make sure it's considered for inclusion at
some point, because I really hope to leverage the "identity" mechanism I
just described, and it's much easier if it's part of a standard instead
of convincing others to go around the standard with us.
I have not spent much tim
As Mike said: the payment protocol doesn't use bitcoin addresses under
the covers.
It is also designed to be easily extensible, so if you want the server
to send the wallet software a public key and multiplier, then add
"publickey" and "multiplier" optional fields to the PaymentDetails (or
maybe O
It's BIP specified and implemented in Bitcoin-Qt so now is the time to
start :) I'm hoping that most wallets can announce support near
simultaneously
On Fri, Aug 9, 2013 at 10:12 PM, Alan Reiner wrote:
> That's fine. I just want to make sure it's considered for inclusion at
> some point,
Payment protocol is locked down for v1 already. But did you read it? It
doesn't use addresses anywhere. Payments are specified in terms of a list
of outputs which can contain any script. Of course it could be a
pay-to-address script, but pay-to-address uses more bytes in the chain and
there isn't a
Guys,
I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol. We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it and
5 matches
Mail list logo
