On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik jgar...@bitpay.com wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
Payment
On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote:
In my opinion encouraging the use of the payment protocol and
deprecating the use of addresses is the best way forward, and not just
for this reason.
There are major gaps that the payment protocol doesn't cover.
There are
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote:
There are major gaps that the payment protocol doesn't cover.
There are several deployed use cases where you are provided/request an
address, an API
Payment Protocol would probably be the communication format for any new
meta-data.
What's the likelihood of something like this every making it on the
blockchain?
--
Want fast and easy access to all the code in your
The request: It would be useful to limit the lifetime of a bitcoin
address.
Not only useful but essential! Otherwise mobile clients can run out of RAM
and have to cycle around and reuse addresses.
Which is indeed why BIP70 has this feature. It was thought about quite some
time ago.
BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.
On Tue, Jul 15, 2014 at 6:25 AM, Mike Hearn m...@plan99.net wrote:
The request: It would be useful to limit the lifetime of a bitcoin
address.
Not only useful but essential! Otherwise mobile
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.
You can specify zero as an output value, in which case it's the same as no
value specified. You can then just reuse the
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
Proxying another's idea, from CoinSummit.
The request: It would be useful to limit the lifetime of a bitcoin
address. Intentionally prevent (somehow) bitcoins being sent to a
pubkey/pkh after the key expires.
You could append
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@dashjr.org wrote:
They can already do this. It's perfectly valid for wallets/services to
ignore (and not consider as payment) transactions using an address more
than once. There might
On Tue, Jul 15, 2014 at 11:41 AM, Luke Dashjr l...@dashjr.org wrote:
There's no reason deposits cannot use a unique payment request or address
every time...
Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests. Payments happen even when
Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests. Payments happen even when
wallets/computers are offline.
I don't understand this point. It's the *sender* that is parsing the
PaymentRequest and following the instructions. By definition
12 matches
Mail list logo
