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=...
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 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,
On Wed, Aug 7, 2013 at 11:44 PM, Mike Hearn wrote:
>
>> My concerns here are:
>> * Making sure wallet applications can function without supporting the
>> P2P protocol (which drops a huge implementation overhead for simple -
>> perhaps hardware-based - wallets)
>
>
> How would such wallets get tran
Very brief comment on BIP 72:
I wonder if there should be some discussion included in the
specification as to how the BIP 21 amount, message and label
parameters should be processed when the payment protocol is used.
Presumably amount should be completely ignored? But is the total
amount request
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.
>
> My concerns here are:
> * Making sure wallet applications can function without supporting the
> P2P protocol (which drops a huge implementation overhead for simple -
> perhaps hardware-based - wallets)
How would such wallets get transactions into their wallet in the first
place?
The P2P protoc
On Wed, Aug 7, 2013 at 11:17 PM, Mike Hearn 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 dou
On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:
If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I wou
> 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
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
On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
I don't like the wording for payment_uri "where the payment _may_ be
sent to obtain a paymentACK", or t
On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying
As you're Mac specific you could just use a modified Sparkle or something
like that. Even if you want to use a stock Sparkle, I have some code that
does threshold RSA. My intention was to use it for the Android wallet but I
never found the time. I can send you a copy if you want. But it's easier
an
That multisignature/blockchain commitment idea seems really solid, Peter.
Thanks very much indeed everyone, this is all very helpful. Much to research
and think about.
Interestingly, a thread is presently raging on liberationtech about Tor Browser
Bundle, and the subject of automatic updates ha
15 matches
Mail list logo
