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 <m...@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/ ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
