Re: [bitcoin-dev] BIP75 - Out of Band Address Exchange

[Andreas Schildbach <andreas@schildbach.de>]

Yes, it makes sense. A BIP is something people refer to, either just by
its number or by URL, and with multiple orthogonal "sub-BIPs" it's
difficult to refer to. We have this problem with BIP32 already -- all HD
wallets implement the derivation part of BIP32 but almost none do
implement the hierarchy part (and use BIP43/44 instead). I tried to
split up BIP32 into two BIPs later (without any content changes), but it
was declined because of its final state.

There is no harm in using a BIP only for a small thing, BIP numbers are
infinite.


On 03/11/2016 08:32 PM, James MacWhyte via bitcoin-dev wrote:
> That's a valid point, and one we had thought of, which is why I wanted
> to get everyone's opinion. I agree the proposed field extensions have
> nothing to do with encryption, but does it make sense to propose a
> completely separate BIP for such a small thing? If that is the accepted
> way to go, we can split it into two and make a separate proposal.
> 
> On Fri, Mar 11, 2016 at 5:48 AM Andreas Schildbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     I think it's a bad idea to pollute the original idea of this BIP with
>     other extensions. Other extensions should go to separate BIPs,
>     especially since methods to clarify the fee have nothing to do with
>     secure and authenticated bi-directional BIP70 communication.
> 
> 
>     On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
>     > Hi everyone,
>     >
>     > Our BIP (officially proposed on March 1) has tentatively been assigned
>     > number 75. Also, the title has been changed to "Out of Band Address
>     > Exchange using Payment Protocol Encryption" to be more accurate.
>     >
>     > We thought it would be good to take this opportunity to add some
>     > optional fields to the BIP70 paymentDetails message. The new
>     fields are:
>     > subtractable fee (give permission to the sender to use some of the
>     > requested amount towards the transaction fee), fee per kb (the minimum
>     > fee required to be accepted as zeroconf), and replace by fee
>     (whether or
>     > not a transaction with the RBF flag will be accepted with zeroconf). I
>     > know it doesn't make much sense for merchants to accept RBF with
>     > zeroconf, so that last one might be used more to explicitly refuse RBF
>     > transactions (and allow the automation of choosing a setting based on
>     > who you are transacting with).
>     >
>     > I see BIP75 as a general modernization of BIP70, so I think it
>     should be
>     > fine to include these extensions in the new BIP, even though these
>     > fields are not specific to the features we are proposing. Please
>     take a
>     > look at the relevant section and let me know if anyone has any
>     concerns:
>     >
>     https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
>     >
>     > The BIP70 extensions page in our fork has also been updated.
>     >
>     > Thanks!
>     >
>     > James
>     >
>     >
>     > _______________________________________________
>     > bitcoin-dev mailing list
>     > bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     >
> 
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>