public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Date: Tue, 15 Jul 2014 17:18:26 +0200	[thread overview]
Message-ID: <CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

>
> Payment protocol just doesn't well the use cases of,
> * an on-going payment stream from, e.g. Eligius to coinbase
> * deposit addresses and deposit situations


This seems to be the key point of disagreement here. Wladimir and I think
it satisfies your requirement just fine. You disagree. Let's get to the
bottom of that.

A PaymentRequest with a zero valued pay-to-address output and an expiration
time, base58 encoded, would look very much like your extended address form.
I don't suggest anyone actually represents PaymentRequest's using base58
but it helps to see the conceptual analogue. There'd be a bit more stuff in
there like some varint and wiretype codes but we're talking a handful of
bytes. Functionally, it'd be identical.

Places like protocols or APIs that require a piece of text and cannot
handle a piece of binary data could be retrofitted into the new world by
accepting base58 encoded PaymentRequest's. This would be kind of silly
because it's fundamentally binary data, but we already do this so it's at
least consistently silly :)

[-- Attachment #2: Type: text/html, Size: 1380 bytes --]

  reply	other threads:[~2014-07-15 15:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15  8:00 [Bitcoin-development] Bitcoin address TTL & key expiration? Jeff Garzik
2014-07-15  8:19 ` Wladimir
2014-07-15  8:23   ` Jeff Garzik
2014-07-15  8:31     ` Jeremy Spilman
2014-07-15  8:48     ` Wladimir
2014-07-15  8:20 ` Peter Todd
2014-07-15 10:25 ` Mike Hearn
2014-07-15 14:02   ` Jeff Garzik
2014-07-15 14:27     ` Mike Hearn
2014-07-15 14:48 ` Luke Dashjr
2014-07-15 15:11   ` Jeff Garzik
2014-07-15 15:18     ` Mike Hearn [this message]
2014-07-15 15:35       ` Jeff Garzik
2014-07-15 15:41     ` Luke Dashjr
2014-07-15 15:55       ` Jeff Garzik
2014-07-15 16:26         ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jgarzik@bitpay.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox