public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@bitpay•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
	Stephane Brossier <stephane@kill-bill•org>,
	Pierre-Alexandre Meyer <pierre@kill-bill•org>
Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration?
Date: Tue, 15 Jul 2014 11:35:03 -0400	[thread overview]
Message-ID: <CAJHLa0Nxav0+VUZoJuiBKXAMMFv1GeGTq0kSn_qeBTizsFRCSQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>

This is a well known problem of BIP 70 from day one, because BIP 70
functions at too-low a level.

What needs to be negotiated between parties is a _payment
relationship_ that exchanges HD wallet data. This is what is necessary
to establish and maintain an ongoing payment relationship.

BIP 70 is focused on singular payments with specific outputs and
values.  BIP 70 wants to transmit an actual transaction.  That does
not fit the use cases described.

Adding in a hack that makes zero-valued outputs behave different does
not change the granularity at which BIP 70 operates.

This is a key reason why I have not just ACK'd the BIP 70 subscription
stuff.  Subscriptions are another example of a longer term payment
relationship.  For such case, you want to exchange HD wallet payment
details.  You do not send or receive outputs.  You might not send
transactions directly to the party (coming instead asynchronously &
unpredictably via blockchain).

BIP 70 marries the _relationship_ with payment transmittal, and the
subscription extension does not change that.

Our "contract" language must get a bit smarter, and include HD wallet
payment details, not necessarily focus on outputs.


On Tue, Jul 15, 2014 at 11:18 AM, Mike Hearn <mike@plan99•net> wrote:
>> 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 :)



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



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

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15  8:00 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
2014-07-15 15:35       ` Jeff Garzik [this message]
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=CAJHLa0Nxav0+VUZoJuiBKXAMMFv1GeGTq0kSn_qeBTizsFRCSQ@mail.gmail.com \
    --to=jgarzik@bitpay$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mike@plan99$(echo .)net \
    --cc=pierre@kill-bill$(echo .)org \
    --cc=stephane@kill-bill$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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