RE: making the bitcoin address in the bitcoin: URI optional:
Ok, I'm convinced, sometimes merchants won't want or need backwards
compatibility and sometimes it won't make sense for them to put an
arbitrary bitcoin: address there.
RE: should the customer's machine not broadcast the transaction:
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
bitcoinj separates the concept of committing a
On 08/07/2013 05:10 PM, Gavin Andresen wrote:
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
I
I see payment URIs rather as a replacement for bitcoin: URI rather
than an extension. It solves everything they did in a much cleaner
way, Given that bitcoin: have gotten some traction, we probably want
to reuse the moniker, but replace the rest entirely. In other words,
if a request is specified,
But the reality is that in many applications you need to provide a
single URL.
Consider existing point-of-sale systems that display QR codes for the
user to scan. They live within the limitations of existing bitcoin
URLs, but would no doubt benefit from the payments protocol.
It's not realistic
I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
the bitcoin address is optional:
If the request parameter is provided and backwards compatibility is
not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?request=...
6 matches
Mail list logo
