From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X74lO-0004Ou-B6 for bitcoin-development@lists.sourceforge.net; Tue, 15 Jul 2014 15:35:30 +0000 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; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X74lN-0002vN-B4 for bitcoin-development@lists.sourceforge.net; Tue, 15 Jul 2014 15:35:30 +0000 Received: by mail-wi0-f177.google.com with SMTP id ho1so4553298wib.10 for ; Tue, 15 Jul 2014 08:35:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bKhXyBkeoE7it9svRDzXXznorVn+j3TfG740AD5NnmE=; b=W+116EIh4KBfW/tztLdtRC6RoW01QQ32qynzMp7UT+hLAsr6kWD/U9BFcepu1dcGXx OvPb+P521db/P+NUKLIufPqMmW96t7OUjUSvLas2GagBL3eEZ3DZDD4gTRJYjpo/N+eu 4nG5/PMHh1Rpp27aLS9iBgmjddLXkuEKKAY/FQJDy6rTBsZo0efzPT/WaxCojPVvizI9 6nMdrsEK+jaNOVeyCLVN+tYCPq+v1QsVtnREVClCNG04o5qKl5+Cixs45GMIEbQU9cq/ OlvgpwVLjNOnATWk+yZNuHyvxVZA5XPAF04kA3T5EIWth+i0Jsy7arBTx9qjPPNK25cp DxoA== X-Gm-Message-State: ALoCoQkrc0WUfKq7raEL83ZbsocLpqedcJK4fi8n+klIGGF7BaLK8dYjHROE4Kzjt7RLKPZHkoq7 X-Received: by 10.181.11.232 with SMTP id el8mr6551985wid.57.1405438523060; Tue, 15 Jul 2014 08:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.67 with HTTP; Tue, 15 Jul 2014 08:35:03 -0700 (PDT) In-Reply-To: References: <201407151448.57223.luke@dashjr.org> From: Jeff Garzik Date: Tue, 15 Jul 2014 11:35:03 -0400 Message-ID: To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X74lN-0002vN-B4 Cc: Bitcoin Dev , Stephane Brossier , Pierre-Alexandre Meyer Subject: Re: [Bitcoin-development] Bitcoin address TTL & key expiration? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:35:30 -0000 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 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/