Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177; envelope-from=jgarzik@bitpay.com;
	helo=mail-wi0-f177.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>
References: <CAJHLa0M7iEUQnJ9M4A3ev3EQqxUVQG85qucRamvMb0n-CztOFA@mail.gmail.com>
	<201407151448.57223.luke@dashjr.org>
	<CAJHLa0Nj2f4mSKNggGH4sXZTLYNwdVGO7uMSzN7V_vVKU-6w9Q@mail.gmail.com>
	<CANEZrP30PLQAebOkoLUphR+6wnwyE7K_BX=bszF8T5UPvai-Lg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 15 Jul 2014 11:35:03 -0400
Message-ID: <CAJHLa0Nxav0+VUZoJuiBKXAMMFv1GeGTq0kSn_qeBTizsFRCSQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
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?
Precedence: list

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/