[bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

BIP 0070 has been a a moderate success, however, IMO:

- protocol buffers are inappropriate since ease of use and extensibility is
desired over the minor gains of efficiency in this protocol.  Not too late
to support JSON messages as the standard going forward

- problematic reliance on merchant-supplied https (X509) as the sole form
of mechant identification.   alternate schemes (dnssec/netki), pgp and
possibly keybase seem like good ideas.   personally, i like keybase, since
there is no reliance on the existing domain-name system (you can sell with
a github id, for example)

- missing an optional client supplied identification

- lack of basic subscription support

*Proposed for subscriptions:*

- BIP0047 payment codes are recommended instead of wallet addresses when
establishing subscriptions.  Or, merchants can specify replacement
addresses in ACK/NACK responses.   UI confirms are *required *when there
are no replacement addresses or payment codes used.

- Wallets must confirm and store subscriptions, and are responsible for
initiating them at the specified interval.

- Intervals can *only *be from a preset list: weekly, biweekly, or 1,
2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
suspension until the user re-verifies.

- Wallets *may *optionally ask the user whether they want to be notified
and confirm every interval - or not.   Wallets that do not ask *must *notify
before initiating each payment.   Interval confirmations should begin at *least
*1 day in advance of the next payment.


*Proposed in general:*
- JSON should be used instead of protocol buffers going forward.  Easier to
use, explain extend.

- "Extendible" URI-like scheme to support multi-mode identity mechanisms on
both payment and subscription requests.   Support for keybase://, netki://
and others as alternates to https://.

- Support for client as well as merchant multi-mode verification

- Ideally, the identity verification URI scheme is somewhat
orthogonal/independent of the payment request itself

Question:

Should this be a new BIP?  I know netki's BIP75 is out there - but I think
it's too specific and too reliant on the domain name system.

Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
major protocols without any mention of payment URI's ... just a way of
sending and receiving identity verified messages in general?

I would be happy to implement plugins for identity protocols, if anyone
thinks this is a good idea.

Does anyone think https:// or keybase, or PGP or netki all by themselves,
is enough - or is it always better to have an extensible protocol?

- Erik Aronesty

[-- Attachment #2: Type: text/html, Size: 3104 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andreas Schildbach]

Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on Protobuf, but that's another story.)

Yes, all extensions to BIP70 should go into new BIPs. Note the plural
here: if you have orthogonal ideas I strongly suggest one BIP per idea
so they can be discussed and implemented (or rejected) separately.


On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
> 
> - protocol buffers are inappropriate since ease of use and extensibility
> is desired over the minor gains of efficiency in this protocol.  Not too
> late to support JSON messages as the standard going forward
> 
> - problematic reliance on merchant-supplied https (X509) as the sole
> form of mechant identification.   alternate schemes (dnssec/netki), pgp
> and possibly keybase seem like good ideas.   personally, i like keybase,
> since there is no reliance on the existing domain-name system (you can
> sell with a github id, for example)
> 
> - missing an optional client supplied identification
> 
> - lack of basic subscription support
> 
> /Proposed for subscriptions:/
> 
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions.  Or, merchants can specify replacement
> addresses in ACK/NACK responses.   UI confirms are /required /when there
> are no replacement addresses or payment codes used.
> 
> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.  
> 
> - Intervals can /only /be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
> suspension until the user re-verifies.
> 
> - Wallets /may /optionally ask the user whether they want to be notified
> and confirm every interval - or not.   Wallets that do not ask /must
> /notify before initiating each payment.   Interval confirmations should
> begin at /least /1 day in advance of the next payment.
> 
> /Proposed in general:
> /
> - JSON should be used instead of protocol buffers going forward.  Easier
> to use, explain extend.
> 
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms
> on both payment and subscription requests.   Support for keybase://,
> netki:// and others as alternates to https://. 
> 
> - Support for client as well as merchant multi-mode verification
> 
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
> 
> Question:
> 
> Should this be a new BIP?  I know netki's BIP75 is out there - but I
> think it's too specific and too reliant on the domain name system.
> 
> Maybe an identity-protocol-agnostic BIP + solid implementation of a
> couple major protocols without any mention of payment URI's ... just a
> way of sending and receiving identity verified messages in general?
> 
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
> 
> Does anyone think https:// or keybase, or PGP or netki all by
> themselves, is enough - or is it always better to have an extensible
> protocol?
> 
> - Erik Aronesty
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having coded both, I can say Protobuf is not more
> difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
> based on Protobuf, but that's another story.)
>

I like protobuf, personally, for C++ stuff.  I just imagined it would be
harder on mobile, or in some languages, to implement.   I'll focus on the
scheduling issue.  Really, that's the only thing I want hashed out.


>
> Yes, all extensions to BIP70 should go into new BIPs. Note the plural
> here: if you have orthogonal ideas I strongly suggest one BIP per idea
> so they can be discussed and implemented (or rejected) separately.
>
>
I think the intervals should *not* be flexible, even at the protocol level,
to prevent attacks designed to confuse users  - plus for shorter intervals,
you need payment channels anyway.  Also, I think the spec should be rigid
with respect to response times, retry periods, etc.... to encourage
consistency among wallet vendors.   Not sure how anyone else feels about
that.  I suspect the netki guys should have opinions, since they are
working on similar UI-stuff.

Should UI standards go somewhere else - not in a BIP?  I do think there
need to be UI standards.  Something with RFC-style should/must/will/wont
language, like "Wallet software *must* show unconfirmed transactions as
distinct from confirmed", and "Wallet software *should *show some visual
indication of other levels of confirmation" ....  stuff like that.

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 5847 bytes --]

Bluetooth exchange of payment requests already has a noticeable lag with 
protocol buffers, so that would be another reason to argue against JSON, 
because JSON is less efficient size wise, correct? I will say that 
although protocol buffers have good platform support, I don't know that 
the documentation for each platform is very good. This is the main 
drawback I see with them. One additional advantage of protocol buffers 
is that the .proto file is a specification, whereas with JSON, you'd 
just have an example file, right?

Isn't keybase a centralized infrastructure? Are you against a blockchain 
based identification? There are a few out there. There is some confusion 
because onename's efforts are breaking away from namecoin though.

I like the idea of PGP signatures of payment requests. This allows for 
manual verification (in my mind, the highest quality) of key 
authenticity (or, with PGP you also have the option to opt into some 
centralized service for key verification). This can be useful when 
dealing with semi-manually issued invoices for goods and services. The 
local bitcoin wallet could just interact with the local PGP keyring. 
Although, one can already just send the payment request in a PGP signed 
e-mail, so I'm not sure if PGP signing is really needed if you're using 
PGP email. The main benefit may just be consolidating/itemizing into 
your bitcoin wallet's transaction history whether the payment 
destination/request was securely received or not. It may also be useful 
for someone to be able to extract a signed payment request from a signed 
PGP e-mail and send it to someone else to make a payment for you (maybe 
you don't want your accounting person to need your entire e-mail 
correspondence with a supplier to be able to just verify the payment 
request and make a payment for your company).

I'm concerned about extending the URI scheme too much. Isn't this going 
to reach the practical size limit of NFC and QR codes pretty quickly?




Andy Schroder

On 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote:
> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having coded both, I can say Protobuf is not more
> difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
> based on Protobuf, but that's another story.)
>
> Yes, all extensions to BIP70 should go into new BIPs. Note the plural
> here: if you have orthogonal ideas I strongly suggest one BIP per idea
> so they can be discussed and implemented (or rejected) separately.
>
>
> On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:
>> BIP 0070 has been a a moderate success, however, IMO:
>>
>> - protocol buffers are inappropriate since ease of use and extensibility
>> is desired over the minor gains of efficiency in this protocol.  Not too
>> late to support JSON messages as the standard going forward
>>
>> - problematic reliance on merchant-supplied https (X509) as the sole
>> form of mechant identification.   alternate schemes (dnssec/netki), pgp
>> and possibly keybase seem like good ideas.   personally, i like keybase,
>> since there is no reliance on the existing domain-name system (you can
>> sell with a github id, for example)
>>
>> - missing an optional client supplied identification
>>
>> - lack of basic subscription support
>>
>> /Proposed for subscriptions:/
>>
>> - BIP0047 payment codes are recommended instead of wallet addresses when
>> establishing subscriptions.  Or, merchants can specify replacement
>> addresses in ACK/NACK responses.   UI confirms are /required /when there
>> are no replacement addresses or payment codes used.
>>
>> - Wallets must confirm and store subscriptions, and are responsible for
>> initiating them at the specified interval.
>>
>> - Intervals can /only /be from a preset list: weekly, biweekly, or 1,
>> 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
>> suspension until the user re-verifies.
>>
>> - Wallets /may /optionally ask the user whether they want to be notified
>> and confirm every interval - or not.   Wallets that do not ask /must
>> /notify before initiating each payment.   Interval confirmations should
>> begin at /least /1 day in advance of the next payment.
>>
>> /Proposed in general:
>> /
>> - JSON should be used instead of protocol buffers going forward.  Easier
>> to use, explain extend.
>>
>> - "Extendible" URI-like scheme to support multi-mode identity mechanisms
>> on both payment and subscription requests.   Support for keybase://,
>> netki:// and others as alternates to https://.
>>
>> - Support for client as well as merchant multi-mode verification
>>
>> - Ideally, the identity verification URI scheme is somewhat
>> orthogonal/independent of the payment request itself
>>
>> Question:
>>
>> Should this be a new BIP?  I know netki's BIP75 is out there - but I
>> think it's too specific and too reliant on the domain name system.
>>
>> Maybe an identity-protocol-agnostic BIP + solid implementation of a
>> couple major protocols without any mention of payment URI's ... just a
>> way of sending and receiving identity verified messages in general?
>>
>> I would be happy to implement plugins for identity protocols, if anyone
>> thinks this is a good idea.
>>
>> Does anyone think https:// or keybase, or PGP or netki all by
>> themselves, is enough - or is it always better to have an extensible
>> protocol?
>>
>> - Erik Aronesty
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Luke Dashjr]

On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
> 
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol.  Not too late
> to support JSON messages as the standard going forward

IMO JSON is too prone to gratuitous inefficiency (both at network and CPU 
level), parser bugs, etc. Even the best C implementation (jansson) has serious 
issues with Number handling.

A few years ago, I looked into binary alternatives to JSON and concluded they 
all had problems, while it seems more than reasonable to do even dynamic 
parsing of protobuf messages. So to conclude, I prefer to stick to protobuf 
unless a clearly superior protocol turns up.

> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification.   alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas.   personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)

X509 is entrenched, so it should remain supported. PGP might make sense for 
people already using it (it provides no real security for un-WoT-networked 
users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC 
Keybase uses blockchain spam, so definitely not something to be encouraged if 
so. Namecoin seems like a more than reasonable decentralised solution, but 
will probably take some real work to implement (not that this is avoidable for 
a general-usage decentralised solution).

> - missing an optional client supplied identification

What do you mean by this? There's the memo field at least.

> - lack of basic subscription support
> 
> *Proposed for subscriptions:*
> 
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions.  Or, merchants can specify replacement
> addresses in ACK/NACK responses.   UI confirms are *required *when there
> are no replacement addresses or payment codes used.

I'd discourage anything using BIP 47 due to its serious design flaws.
No reason a regular BIP 32 pub seed can't be used instead.

What do you mean by "replacement addresses" and "UI confirms" here?

> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
> 
> - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
> suspension until the user re-verifies.

Disagree with hard-coding intervals, or mandating specific policies from the 
service providers.

> - Wallets *may *optionally ask the user whether they want to be notified
> and confirm every interval - or not.   Wallets that do not ask *must
> *notify before initiating each payment.   Interval confirmations should
> begin at *least *1 day in advance of the next payment.

This is wallet policy, but maybe makes sense as a "best practices" BIP.

> *Proposed in general:*
> - JSON should be used instead of protocol buffers going forward.  Easier to
> use, explain extend.
> 
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms on
> both payment and subscription requests.   Support for keybase://, netki://
> and others as alternates to https://.
> 
> - Support for client as well as merchant multi-mode verification
> 
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
> 
> Question:
> 
> Should this be a new BIP?  I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>
> Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
> major protocols without any mention of payment URI's ... just a way of
> sending and receiving identity verified messages in general?
> 
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
> 
> Does anyone think https:// or keybase, or PGP or netki all by themselves,
> is enough - or is it always better to have an extensible protocol?
> 
> - Erik Aronesty

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

Thanks for starting this discussion, Erik.


> Should this be a new BIP?  I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>

This is not quite accurate. BIP75 is designed to be independent of any name
resolution system. You could use it with a static URL that you share, for
example, or even use it to implement a mesh-network payment system over
bluetooth. Netki's wallet names do use DNS, but that isn't related to this
discussion.

What BIP75 *does* do is provide a way for a client to get a new payment
address for every payment. I personally think it is better than BIP47 for
the uses you mentioned (subscriptions, etc).

I'm glad you brought up identity methods other than x509. At breadwallet we
are thinking about how to establish the most universal system, and letting
users identify themselves with any of a selection of identity systems is
ideal. I think the pki_data slot should be constantly expanded to allow new
identity types, but they should be explained/standardized in the BIPs that
add them and use universal names. "netki://" wouldn't be appropriate, for
example, if their method is open sourced and possibly used by others--it
should instead be given a product name like "dnswallet://" or something
more clever.

James

[-- Attachment #2: Type: text/html, Size: 1981 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Matt David]

[-- Attachment #1.1: Type: text/plain, Size: 4113 bytes --]

Hey all,

Interestingly enough, the original BIP75 idea started by trying to move the Payment Protocol to use JSON, but because of all of the reasons mentioned by Andreas, we ended up with protobuf. There is quite a bit of language support on both desktop and mobile platforms so that's become mostly a non-issue.

Regarding the lack of optional client-supplied identification, BIP75 was designed to solve this issue. It allows both parties in a transaction to share identity information in an out-of-band fashion in order to keep specific identity information off-chain.

With regards to extensibility of PKI usage, both BIP70 and BIP75 provide plenty of flexibility. Both the InvoiceRequest and PaymentRequest contain the pki_type and pki_data fields to allow for the use of non X.509 certificates. Currently, the only pki_types specified in both BIPs are none or x509_sha256, but there isn't any specific limit on what can be used as long as you can define a PKI type to be used, include a public key and a signature that proves control of the keypair. Perhaps a new BIP allowing for additional PKI types can be submitted, similar to how RFCs extend usage of ciphers for TLS (ie., RFC 5932).

Regarding subscriptions, and as proposed in the address book example use case in BIP75, a wallet can be setup to automatically create BIP75 transactions in order to retrieve a wallet address to pay for a subscription on whatever frequency you would like to use. The service provider can approve the first BIP75 transaction and then store the public key for that client for future use. For subsequent subscription payments, the service provider may automatically return wallet addresses for each BIP75 transaction, understanding that the subsequent BIP75 transactions are linked to the public key that was used for the first transaction and therefore the subscription has been paid for. Additionally, the BIP75 InvoiceRequest message contains a memo field that can be used to include any additional subscription information required by the subscription provider (and can be different for both first and subsequent BIP75 transactions).

This is a very interesting idea and I'd love to see how the community can work together to make Bitcoin more user and mainstream friendly while increasing security for all parties involved. All movement toward this is really the goal at Netki.

Best,

Matt David
Sr. Software Engineer
Netki, Inc.

matt@netki.com



> On Jun 21, 2016, at 1:56 PM, James MacWhyte via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Thanks for starting this discussion, Erik.
> 
> 
> Should this be a new BIP?  I know netki's BIP75 is out there - but I think it's too specific and too reliant on the domain name system.
> 
> This is not quite accurate. BIP75 is designed to be independent of any name resolution system. You could use it with a static URL that you share, for example, or even use it to implement a mesh-network payment system over bluetooth. Netki's wallet names do use DNS, but that isn't related to this discussion.
> 
> What BIP75 *does* do is provide a way for a client to get a new payment address for every payment. I personally think it is better than BIP47 for the uses you mentioned (subscriptions, etc).
> 
> I'm glad you brought up identity methods other than x509. At breadwallet we are thinking about how to establish the most universal system, and letting users identify themselves with any of a selection of identity systems is ideal. I think the pki_data slot should be constantly expanded to allow new identity types, but they should be explained/standardized in the BIPs that add them and use universal names. "netki://" wouldn't be appropriate, for example, if their method is open sourced and possibly used by others--it should instead be given a product name like "dnswallet://" or something more clever.
> 
> James
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2.1: Type: text/html, Size: 10193 bytes --]

[-- Attachment #1.2.2: PastedGraphic-2.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 5715 bytes --]

> keybase spam

good point about keybase spam, but i think it's limited to once hash per
hour (?), not really too bad... the tx's are just root signatures, so you
can verify a whole keybase tree (up to the last hour) with very minimal
bitcoin blockchain impact.

> What do you mean by "replacement addresses" and "UI confirms" here?

"Replacement addresses" would take the place of BIP 32/47 support, if
someone thought maybe that was too difficult to deal with.   So each time i
paid Alice, Alice could generate a new payment address for the next monthly
payment.   If you support BIP 32 pub seed, then there's no need for this.
I don't know any wallets that support a BIP 32 pub seed (and then what,
some random number generator?) as a destination address yet.

> Disagree with hard-coding intervals, or mandating specific policies from
the
service providers.

I think mandating is a harsh word here, but i I'm a strong believer in
providing strict guidelines that if people break, others can call them
on.   Giving someone a 12.3 +/- 5 day interval for payments using this
protocol would suck.   You should use payment channels for that stuff.
The idea is a lightweight protocol for getting monthly subscriptions
working.




On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr <luke@dashjr.org> wrote:

> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> > BIP 0070 has been a a moderate success, however, IMO:
> >
> > - protocol buffers are inappropriate since ease of use and extensibility
> is
> > desired over the minor gains of efficiency in this protocol.  Not too
> late
> > to support JSON messages as the standard going forward
>
> IMO JSON is too prone to gratuitous inefficiency (both at network and CPU
> level), parser bugs, etc. Even the best C implementation (jansson) has
> serious
> issues with Number handling.
>
> A few years ago, I looked into binary alternatives to JSON and concluded
> they
> all had problems, while it seems more than reasonable to do even dynamic
> parsing of protobuf messages. So to conclude, I prefer to stick to protobuf
> unless a clearly superior protocol turns up.
>
> > - problematic reliance on merchant-supplied https (X509) as the sole form
> > of mechant identification.   alternate schemes (dnssec/netki), pgp and
> > possibly keybase seem like good ideas.   personally, i like keybase,
> since
> > there is no reliance on the existing domain-name system (you can sell
> with
> > a github id, for example)
>
> X509 is entrenched, so it should remain supported. PGP might make sense for
> people already using it (it provides no real security for un-WoT-networked
> users), but unforunately, few people use it. Correct me if I'm wrong, but
> IIRC
> Keybase uses blockchain spam, so definitely not something to be encouraged
> if
> so. Namecoin seems like a more than reasonable decentralised solution, but
> will probably take some real work to implement (not that this is avoidable
> for
> a general-usage decentralised solution).
>
> > - missing an optional client supplied identification
>
> What do you mean by this? There's the memo field at least.
>
> > - lack of basic subscription support
> >
> > *Proposed for subscriptions:*
> >
> > - BIP0047 payment codes are recommended instead of wallet addresses when
> > establishing subscriptions.  Or, merchants can specify replacement
> > addresses in ACK/NACK responses.   UI confirms are *required *when there
> > are no replacement addresses or payment codes used.
>
> I'd discourage anything using BIP 47 due to its serious design flaws.
> No reason a regular BIP 32 pub seed can't be used instead.
>
> What do you mean by "replacement addresses" and "UI confirms" here?
>
> > - Wallets must confirm and store subscriptions, and are responsible for
> > initiating them at the specified interval.
> >
> > - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> > 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
> > suspension until the user re-verifies.
>
> Disagree with hard-coding intervals, or mandating specific policies from
> the
> service providers.
>
> > - Wallets *may *optionally ask the user whether they want to be notified
> > and confirm every interval - or not.   Wallets that do not ask *must
> > *notify before initiating each payment.   Interval confirmations should
> > begin at *least *1 day in advance of the next payment.
>
> This is wallet policy, but maybe makes sense as a "best practices" BIP.
>
> > *Proposed in general:*
> > - JSON should be used instead of protocol buffers going forward.  Easier
> to
> > use, explain extend.
> >
> > - "Extendible" URI-like scheme to support multi-mode identity mechanisms
> on
> > both payment and subscription requests.   Support for keybase://,
> netki://
> > and others as alternates to https://.
> >
> > - Support for client as well as merchant multi-mode verification
> >
> > - Ideally, the identity verification URI scheme is somewhat
> > orthogonal/independent of the payment request itself
> >
> > Question:
> >
> > Should this be a new BIP?  I know netki's BIP75 is out there - but I
> think
> > it's too specific and too reliant on the domain name system.
> >
> > Maybe an identity-protocol-agnostic BIP + solid implementation of a
> couple
> > major protocols without any mention of payment URI's ... just a way of
> > sending and receiving identity verified messages in general?
> >
> > I would be happy to implement plugins for identity protocols, if anyone
> > thinks this is a good idea.
> >
> > Does anyone think https:// or keybase, or PGP or netki all by
> themselves,
> > is enough - or is it always better to have an extensible protocol?
> >
> > - Erik Aronesty
>

[-- Attachment #2: Type: text/html, Size: 6936 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

On Tue, Jun 21, 2016 at 08:44:37PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> > BIP 0070 has been a a moderate success, however, IMO:
> > 
> > - protocol buffers are inappropriate since ease of use and extensibility is
> > desired over the minor gains of efficiency in this protocol.  Not too late
> > to support JSON messages as the standard going forward
> 
> IMO JSON is too prone to gratuitous inefficiency (both at network and CPU 
> level), parser bugs, etc. Even the best C implementation (jansson) has serious 
> issues with Number handling.
> 
> A few years ago, I looked into binary alternatives to JSON and concluded they 
> all had problems, while it seems more than reasonable to do even dynamic 
> parsing of protobuf messages. So to conclude, I prefer to stick to protobuf 
> unless a clearly superior protocol turns up.

I'll second that statement.

Ease of use isn't a very good criteria for security-critical software handling
money, and the JSON standard has a very large amount of degrees of freedom in
how people have implemented it historically. Even protobuf I'd personally avoid
using on that basis, as protobuf encoding isn't deterministic: you can encode
the same data in multiple ways.

Unfortunately there isn't a viable alternative, so we're probably stuck with
protobuf right now for standards that want to see wide adoption in the near
future; I've got a few projects that need an alternative, which I'm working on,
but that's a ways off.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
> 
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol.  Not too late
> to support JSON messages as the standard going forward
> 
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification.   alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas.   personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
> 
> - missing an optional client supplied identification

Note that "client supplied identification" is being pushed for AML/KYC
compliance, e.g. Netki's AML/KYC compliance product:

http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/

This is an extremely undesirable feature to be baking into standards given it's
negative impact on fungibility and privacy; we should not be adopting standards
with AML/KYC support, for much the same reasons that the W3C should not be
standardizing DRM.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Tue, Jun 21, 2016 at 08:44:37PM +0000, Luke Dashjr via bitcoin-dev wrote:
> X509 is entrenched, so it should remain supported. PGP might make sense for 
> people already using it (it provides no real security for un-WoT-networked 
> users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC 
> Keybase uses blockchain spam, so definitely not something to be encouraged if 

How else would you have keybase accomplish what they're accomplishing, with the
same security model?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

> Note that "client supplied identification" is being pushed for AML/KYC
> compliance, e.g. Netki's AML/KYC compliance product:
>
>
> http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
>
> This is an extremely undesirable feature to be baking into standards given
> it's
> negative impact on fungibility and privacy; we should not be adopting
> standards
> with AML/KYC support, for much the same reasons that the W3C should not be
> standardizing DRM.
>
>
KYC isn't the only use case. There are other situations in which you would
want to confirm who is sending you money. Making it *required* would of
course be a horrible idea, but allowing people to identify themselves, in
many cases with an online-only identity that isn't tied to their real world
identity, will be very useful to newly-developing use cases.

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Tue, Jun 21, 2016 at 10:50:36PM +0000, James MacWhyte wrote:
> > Note that "client supplied identification" is being pushed for AML/KYC
> > compliance, e.g. Netki's AML/KYC compliance product:
> >
> >
> > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
> >
> > This is an extremely undesirable feature to be baking into standards given
> > it's
> > negative impact on fungibility and privacy; we should not be adopting
> > standards
> > with AML/KYC support, for much the same reasons that the W3C should not be
> > standardizing DRM.
> >
> >
> KYC isn't the only use case. There are other situations in which you would
> want to confirm who is sending you money. Making it *required* would of
> course be a horrible idea, but allowing people to identify themselves, in
> many cases with an online-only identity that isn't tied to their real world
> identity, will be very useful to newly-developing use cases.

It's easy to confirm who is sending you money: give out different addresses to
different people, and keep those addresses private.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Justin Newton]

[-- Attachment #1.1: Type: text/plain, Size: 3057 bytes --]

On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev
> wrote:
>
> > - missing an optional client supplied identification
>
> Note that "client supplied identification" is being pushed for AML/KYC
> compliance, e.g. Netki's AML/KYC compliance product:
>
>
> http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
>
> This is an extremely undesirable feature to be baking into standards given
> it's
> negative impact on fungibility and privacy; we should not be adopting
> standards
> with AML/KYC support, for much the same reasons that the W3C should not be
> standardizing DRM.
>

Hi Peter,
   Certainly AML/KYC compliance is one of the use cases that BIP 75 and our
certificates can support.  As a quick summary,

There are individuals and entities that would like to buy, sell, and use
bitcoin, and other public blockchains, but that have compliance
requirements that they need to meet before they can do so.  Similarly,
companies and entrepreneurs in the space suffer under the potential threat
of fines, or in extreme cases, jail time, also for not meeting AML or
sanctions list compliance.  We wanted to build tools that allowed
entrepreneurs to breathe easy, while at the same time allow more people and
companies to enter the ecosystem.  We also believe that the solution we are
using has the characteristics that you want in such a solution, for example:

1> Only the counterparties (and possibly their service providers in the
case of hosted services) in a transaction can see the identity data,
protecting user privacy.

2> The counterparties themselves (and possibly their service providers in
the case of hosted services) decide whether identity information is
required for any given transaction.

3> No trace is left on the blockchain or anywhere else (other than with the
counterparties) that identity information was even exchanged, protecting
fungibility

4> The solution is based on open source and open standards, allowing open
permissionless innovation, versus parties building closed networks based on
closed standards.  The very fact that this solution went through the BIP
process and was adapted based on feedback is an example of how this is
better for users than the inevitable closed solution that would arise if
the open source, community vetted version didn’t already exist.

I don’t know if you are opposed to organizations that have AML requirements
from using the bitcoin blockchain, but if you aren’t, why wouldn’t you
prefer an open source, open standards based solution to exclusionary,
proprietary ones?

BIP 70 and BIP 75 are standards for voluntary information exchange between
counterparties in a transaction.  This is exactly the kind of thing we want
standards for, in my experience.


-- 

Justin W. Newton
Founder/CEO
Netki, Inc.

justin@netki.com
+1.818.261.4248

[-- Attachment #1.2: Type: text/html, Size: 5057 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Luke Dashjr]

On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
> > What do you mean by "replacement addresses" and "UI confirms" here?
> 
> "Replacement addresses" would take the place of BIP 32/47 support, if
> someone thought maybe that was too difficult to deal with.   So each time i
> paid Alice, Alice could generate a new payment address for the next monthly
> payment.   If you support BIP 32 pub seed, then there's no need for this.

I suppose it makes sense that since every payment requires communication with 
the recipient, that the recipient could give you a new scriptPubKey each time. 
No need to save [potentially compromised] payment info in advance?

> I don't know any wallets that support a BIP 32 pub seed (and then what,
> some random number generator?) as a destination address yet.

The point, as I see it, of payment protocol(s) is to deprecate addresses.
ie, this new protocol *could be* the BIP 32 pub seed destination address. ;)

> > Disagree with hard-coding intervals, or mandating specific policies from
> > the service providers.
> 
> I think mandating is a harsh word here, but i I'm a strong believer in
> providing strict guidelines that if people break, others can call them
> on.   Giving someone a 12.3 +/- 5 day interval for payments using this
> protocol would suck.   You should use payment channels for that stuff.
> The idea is a lightweight protocol for getting monthly subscriptions
> working.

Maybe just a field specifying how far in advance payments should be sent, 
then?

Luke

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Thomas Voegtlin]

IMO the moderate success of BIP70 is caused by its complexity. Since the
amount of data in a BIP70 payment request does not fit in a bitcoin:
URI, an https server is required to serve the requests.

Only large merchants are able to maintain such an infrastructure; (even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.

The main benefit of BIP70 is that the payment request is signed by the
requestor; this gives the sender a proof that they are sending to the
right person, and that the person actually requested the payment.

The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a Bitcoin URI
and to be shared by QR code or SMS text.

 bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz

The URI scheme is extended with two fields:
 name: DNS name containing a public key or bitcoin address
 sig: signature

That extension is sufficient to provide authenticated requests, without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra data from
the requestor. The only assumption is that the verifier is able to make
DNS requests.

I am willing to write a BIP if other wallet developers are interested.




Le 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :
> BIP 0070 has been a a moderate success, however, IMO:
> 
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol.  Not too late
> to support JSON messages as the standard going forward
> 
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification.   alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas.   personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
> 
> - missing an optional client supplied identification
> 
> - lack of basic subscription support
> 
> *Proposed for subscriptions:*
> 
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions.  Or, merchants can specify replacement
> addresses in ACK/NACK responses.   UI confirms are *required *when there
> are no replacement addresses or payment codes used.
> 
> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
> 
> - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
> suspension until the user re-verifies.
> 
> - Wallets *may *optionally ask the user whether they want to be notified
> and confirm every interval - or not.   Wallets that do not ask *must *notify
> before initiating each payment.   Interval confirmations should begin at *least
> *1 day in advance of the next payment.
> 
> 
> *Proposed in general:*
> - JSON should be used instead of protocol buffers going forward.  Easier to
> use, explain extend.
> 
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms on
> both payment and subscription requests.   Support for keybase://, netki://
> and others as alternates to https://.
> 
> - Support for client as well as merchant multi-mode verification
> 
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
> 
> Question:
> 
> Should this be a new BIP?  I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
> 
> Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
> major protocols without any mention of payment URI's ... just a way of
> sending and receiving identity verified messages in general?
> 
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
> 
> Does anyone think https:// or keybase, or PGP or netki all by themselves,
> is enough - or is it always better to have an extensible protocol?
> 
> - Erik Aronesty
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

> Only large merchants are able to maintain such an infrastructure; (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>

Payment protocol is for when you buy stuff from purse.io, not really needed
for face-to face transfers, end users, IMO.


> The same benefit can be achieved without the complexity of BIP70, by
> extending the Bitcoin URI scheme. The requestor is authenticated using
> DNSSEC, and the payment request is signed using an EC private key. A
> domain name and an EC signature are short enough to fit in a Bitcoin URI
> and to be shared by QR code or SMS text.
>
>  bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz
>

I agree.  A TXT record at that name could contain the pubkey.


> That extension is sufficient to provide authenticated requests, without
> requiring a https server. The signed data can be serialized from the
> URI, and DNSSEC verification succeeds without requesting extra data from
> the requestor. The only assumption is that the verifier is able to make
> DNS requests.
>

The problem is that there's no way for a merchant to *refuse *a payment
without a direct communication with the merchant's server.    Verify first
/ clear later is the rule.   Check stock, ensure you can deliver, and clear
the payment on the way out the door.

Also, as a merchant processing monthly subscriptions, you don't want the
first time you hear about a user's payment to be *after *it hits the
blockchain.  You could add a refund address to deal with it after the
fact... stuff a refund address int OP_RETURN somehow?

bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com
&offset=3d&interval=1m&sig=zzz

... But what if the merchant simply goes out of business.  No OP_RETURN
will help you here.   You'll be posting transactions into a dead wallet.
You could have some way of posting a "ping" transaction, and then
monitoring for a valid response.   But this is "spamming the blockchain for
communications".

No, I think BIP075 is fine.   You just need to extend the *PaymentAck *with
a single field, instead of just having a memo.

next_payment_days : integer

The wallet, when it sees this field, re-initiates an invoice request after
the selected number of days, after presenting the user with the content of
the memo field which will presumably explain the subscription.   Wallet
vendors can let users "auto approve" vendors as needed.

This is, I think, the absolute minimum needed to update BIP0070/0075 for
subscriptions.

[-- Attachment #2: Type: text/html, Size: 3838 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder]

[-- Attachment #1.1.1: Type: text/plain, Size: 4098 bytes --]




>
>     Only large merchants are able to maintain such an infrastructure;
>     (even
>     Coinbase recently failed at it, they forgot to update their
>     certificate). For end users that is completely unpractical.
>
>
> Payment protocol is for when you buy stuff from purse.io 
> <http://purse.io>, not really needed for face-to face transfers, end 
> users, IMO.



I disagree with your statements. There are many face to face use cases 
where the payment protocol is essential. Pretty much anything where the 
payee's hardware device that the payer interacts with is automated in 
public and/or operated or accessible by untrusted employees. In any of 
those cases the software on the payee's hardware device can be modified. 
Providing a signed payment request gives the payer additional confidence 
that they are paying the correct person.

See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/


There was a secure bluetooth protocol that Andreas Schildbach and Eric 
Voskuil and I were working on, but we never pulled it all the way 
together. This would also need a two way exchange for a face to face 
payment. This could be used without using some sort of key/certificate 
verification service if being done between two humans who are the direct 
senders and receivers of the payment and are using hardware that they 
personally own (not necessarily the case of untrusted employees or 
public vulnerable machines).




>     The same benefit can be achieved without the complexity of BIP70, by
>     extending the Bitcoin URI scheme. The requestor is authenticated using
>     DNSSEC, and the payment request is signed using an EC private key. A
>     domain name and an EC signature are short enough to fit in a
>     Bitcoin URI
>     and to be shared by QR code or SMS text.
>
>      bitcoin:address?amount=xx&message=yyy&name=john.example.com
>     <http://john.example.com>&sig=zzz
>
>
> I agree.  A TXT record at that name could contain the pubkey.


Did you not see my previous message about the size of the bitcoin: URI 
getting too big for NFC and QR codes? Do you not care about giving the 
payer the option of using multiple destination payment addresses? This 
is important for many reasons.


>     That extension is sufficient to provide authenticated requests,
>     without
>     requiring a https server. The signed data can be serialized from the
>     URI, and DNSSEC verification succeeds without requesting extra
>     data from
>     the requestor. The only assumption is that the verifier is able to
>     make
>     DNS requests.
>
>
> The problem is that there's no way for a merchant to /refuse /a 
> payment without a direct communication with the merchant's server.    
> Verify first / clear later is the rule.   Check stock, ensure you can 
> deliver, and clear the payment on the way out the door.

So, are you saying first the payer should send an unsigned transaction 
for review, and then once the payee has agreed it's good, they can send 
an ACK message back and then wait for the signed version? I don't think 
this is a bad option to have. Many wallets simultaneously broadcast a 
signed transaction to their peers and and also back to the payee via 
https or bluetooth. So, you'd have to add another step to do the 
unsigned transaction review in order to avoid a transaction being 
accidentally broadcast that both parties don't like.


>
> Also, as a merchant processing monthly subscriptions, you don't want 
> the first time you hear about a user's payment to be /after /it hits 
> the blockchain.  You could add a refund address to deal with it after 
> the fact... stuff a refund address int OP_RETURN somehow?
>
> bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com 
> <http://john.example.com>&offset=3d&interval=1m&sig=zzz

Again, my comments above about issues with using bitcoin: URI for 
everything. Also, why do you want to bloat the blockchain with 
unnecessary refund transaction data?



[-- Attachment #1.1.2: Type: text/html, Size: 7745 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

> Again, my comments above about issues with using bitcoin: URI for
everything. Also, why do you want to bloat the blockchain with unnecessary
refund transaction data?

I don't, sorry -  I was just kind of thinking out loud and explaining what
happens when you stuff that into a URL.

My conclusion at the bottom of that post was to keep BIP 75 the same, don't
change a bit, and stick any subscription information (future payment
schedule) in the PaymentACK.   Then the wallet then re-initiates an invoice
(unattended or attended.. up to the user), after the subscription interval
is passed.  Subscriptions are pretty important for Bitcoin to be used as a
real payment system.


​

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 1905 bytes --]

I understand the need for people to make repeated payments to 
individuals in real life that they know, without the payee every even 
taking the effort to make a formal payment request (say you're just 
paying a family member of friend back for picking something up for you 
at the store, and you've already payed them many times before).

For a subscription, wouldn't it be better to promote payment channels or 
just send another payment request? I've been brainstorming recently 
about a model where service providers could deliver invoices, receipts, 
and payment requests in a standardized and secure way. In addition to 
having a send, receive, and transaction history tab in your bitcoin 
wallet, you'd also have an open payment channels tab (which would 
include all applications on your computer that have an open real time 
payment channel, such as a wifi access point, web browser, voip 
provider, etc.), as well as a "bills to pay" tab. Since everything would 
be automated and consolidated locally, you wouldn't have to deal with 
logging into a million different websites to get the bills and then pay 
them. If it were this easy, why would you ever want to do a recurring 
payment from a single payment request? I understand why you may think 
you want to given current work flows, but I'm wondering if it may be 
better to just skip over to a completely better way of doing things.


Andy Schroder

On 06/22/2016 11:30 AM, Erik Aronesty wrote:
> My conclusion at the bottom of that post was to keep BIP 75 the same, 
> don't change a bit, and stick any subscription information (future 
> payment schedule) in the PaymentACK.   Then the wallet then 
> re-initiates an invoice (unattended or attended.. up to the user), 
> after the subscription interval is passed. Subscriptions are pretty 
> important for Bitcoin to be used as a real payment system. 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

- Payment channels seem clearly inappropriate for things like monthly
subscriptions, the use of nlocktime, etc.

- Merchants cannot send requests to users for future payments, because
users don't run servers that they can connect to.  That's why BIP0070 works
the way it does.

- Need to have an interval for subscriptions, at a minimum, and stored in
the wallet so next months payment can go out on time

- Support for varying currency conversion needs to be baked in to
wallets.   Fortunately, by adding advisory subscription info to the
paymentrequest, this is left up to the wallet to
secure/validate/repeat/convert/etc. as needed for each subscription.

- The UI you describe is nice - but not unique to the solution.




On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder.com>
wrote:

> I understand the need for people to make repeated payments to individuals
> in real life that they know, without the payee every even taking the effort
> to make a formal payment request (say you're just paying a family member of
> friend back for picking something up for you at the store, and you've
> already payed them many times before).
>
> For a subscription, wouldn't it be better to promote payment channels or
> just send another payment request? I've been brainstorming recently about a
> model where service providers could deliver invoices, receipts, and payment
> requests in a standardized and secure way. In addition to having a send,
> receive, and transaction history tab in your bitcoin wallet, you'd also
> have an open payment channels tab (which would include all applications on
> your computer that have an open real time payment channel, such as a wifi
> access point, web browser, voip provider, etc.), as well as a "bills to
> pay" tab. Since everything would be automated and consolidated locally, you
> wouldn't have to deal with logging into a million different websites to get
> the bills and then pay them. If it were this easy, why would you ever want
> to do a recurring payment from a single payment request? I understand why
> you may think you want to given current work flows, but I'm wondering if it
> may be better to just skip over to a completely better way of doing things.
>
>
> Andy Schroder
>
>
> On 06/22/2016 11:30 AM, Erik Aronesty wrote:
>
>> My conclusion at the bottom of that post was to keep BIP 75 the same,
>> don't change a bit, and stick any subscription information (future payment
>> schedule) in the PaymentACK.   Then the wallet then re-initiates an invoice
>> (unattended or attended.. up to the user), after the subscription interval
>> is passed. Subscriptions are pretty important for Bitcoin to be used as a
>> real payment system.
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3371 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 4051 bytes --]

Thomas,

I like your idea about expanding Bitcoin URI's to include signatures. For
BIP75 store and forward servers we are already thinking the DNS record
would have the user's public key as well as the URL of their store and
forward endpoint, so as soon as that becomes a standard you could use it
just for the public key part. Expanding the Bitcoin URI should be done as
well, for people who want to go the simpler route and not rely on servers.

Erik, Andy, everyone else,

I don't understand why subscriptions would need to be built into the
protocol. With BIP75 the merchant could automatically issue a
PaymentRequest message every X amount of time, and the customer's wallet
would either display the request like normal or be set to pre-authorize
requests from the merchant. If the merchant goes out of business, the
requests would stop coming. This sounds like a UI issue and not a
protocol-level requirement.

If you think I'm wrong, please explain why :)

On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> - Payment channels seem clearly inappropriate for things like monthly
> subscriptions, the use of nlocktime, etc.
>
> - Merchants cannot send requests to users for future payments, because
> users don't run servers that they can connect to.  That's why BIP0070 works
> the way it does.
>
> - Need to have an interval for subscriptions, at a minimum, and stored in
> the wallet so next months payment can go out on time
>
> - Support for varying currency conversion needs to be baked in to
> wallets.   Fortunately, by adding advisory subscription info to the
> paymentrequest, this is left up to the wallet to
> secure/validate/repeat/convert/etc. as needed for each subscription.
>
> - The UI you describe is nice - but not unique to the solution.
>
>
>
>
> On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder.com>
> wrote:
>
>> I understand the need for people to make repeated payments to individuals
>> in real life that they know, without the payee every even taking the effort
>> to make a formal payment request (say you're just paying a family member of
>> friend back for picking something up for you at the store, and you've
>> already payed them many times before).
>>
>> For a subscription, wouldn't it be better to promote payment channels or
>> just send another payment request? I've been brainstorming recently about a
>> model where service providers could deliver invoices, receipts, and payment
>> requests in a standardized and secure way. In addition to having a send,
>> receive, and transaction history tab in your bitcoin wallet, you'd also
>> have an open payment channels tab (which would include all applications on
>> your computer that have an open real time payment channel, such as a wifi
>> access point, web browser, voip provider, etc.), as well as a "bills to
>> pay" tab. Since everything would be automated and consolidated locally, you
>> wouldn't have to deal with logging into a million different websites to get
>> the bills and then pay them. If it were this easy, why would you ever want
>> to do a recurring payment from a single payment request? I understand why
>> you may think you want to given current work flows, but I'm wondering if it
>> may be better to just skip over to a completely better way of doing things.
>>
>>
>> Andy Schroder
>>
>>
>> On 06/22/2016 11:30 AM, Erik Aronesty wrote:
>>
>>> My conclusion at the bottom of that post was to keep BIP 75 the same,
>>> don't change a bit, and stick any subscription information (future payment
>>> schedule) in the PaymentACK.   Then the wallet then re-initiates an invoice
>>> (unattended or attended.. up to the user), after the subscription interval
>>> is passed. Subscriptions are pretty important for Bitcoin to be used as a
>>> real payment system.
>>>
>>
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5141 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 5655 bytes --]

> I don't understand why subscriptions would need to be built into the
protocol.

Simple: Because the PaymentRequest is somewhat counter-intuitively a
/response/ to a customer initiated action.   It's not something the
merchant can initiate (of course, logically this makes sense... how can a
merchant know how to connect to some random android app).

Customers initiate all InvoiceRequests  BIP0075 clarifies this.   BIP0070
merely says that the customer "somehow indicates they are ready to pay".
BIP0075 formalizes a standard way to do this.

In no way do merchants initiate anything (of course).   Subscription
information must reside in the customers wallet, in response to a
merchant's advice to set up subscription.   Tacking parameters on to a
PaymentRequest or PaymentAck is the only good way to do this within BIP
70/75.

The only thing to hash out is exactly what fields to tack on and what they
mean.  ( subscription amount / currency / interval / interval_type ...
can't think of anything else )

Wallets are responsible for initiating the subscriptions on behalf of the
user.  Recommendations on how to do this should go into the spec.

Of course any wallet can, with BIP0075 add support for subscriptions
without any spec - just let the user set them up manually.   But it would
be nice if a user didn't have to enter the main parameters for
subscriptions... too easy to get times amounts, etc wrong.


On Wed, Jun 22, 2016 at 4:11 PM, James MacWhyte <macwhyte@gmail.com> wrote:

> Thomas,
>
> I like your idea about expanding Bitcoin URI's to include signatures. For
> BIP75 store and forward servers we are already thinking the DNS record
> would have the user's public key as well as the URL of their store and
> forward endpoint, so as soon as that becomes a standard you could use it
> just for the public key part. Expanding the Bitcoin URI should be done as
> well, for people who want to go the simpler route and not rely on servers.
>
> Erik, Andy, everyone else,
>
> I don't understand why subscriptions would need to be built into the
> protocol. With BIP75 the merchant could automatically issue a
> PaymentRequest message every X amount of time, and the customer's wallet
> would either display the request like normal or be set to pre-authorize
> requests from the merchant. If the merchant goes out of business, the
> requests would stop coming. This sounds like a UI issue and not a
> protocol-level requirement.
>
> If you think I'm wrong, please explain why :)
>
> On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> - Payment channels seem clearly inappropriate for things like monthly
>> subscriptions, the use of nlocktime, etc.
>>
>> - Merchants cannot send requests to users for future payments, because
>> users don't run servers that they can connect to.  That's why BIP0070 works
>> the way it does.
>>
>> - Need to have an interval for subscriptions, at a minimum, and stored in
>> the wallet so next months payment can go out on time
>>
>> - Support for varying currency conversion needs to be baked in to
>> wallets.   Fortunately, by adding advisory subscription info to the
>> paymentrequest, this is left up to the wallet to
>> secure/validate/repeat/convert/etc. as needed for each subscription.
>>
>> - The UI you describe is nice - but not unique to the solution.
>>
>>
>>
>>
>> On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder.com>
>> wrote:
>>
>>> I understand the need for people to make repeated payments to
>>> individuals in real life that they know, without the payee every even
>>> taking the effort to make a formal payment request (say you're just paying
>>> a family member of friend back for picking something up for you at the
>>> store, and you've already payed them many times before).
>>>
>>> For a subscription, wouldn't it be better to promote payment channels or
>>> just send another payment request? I've been brainstorming recently about a
>>> model where service providers could deliver invoices, receipts, and payment
>>> requests in a standardized and secure way. In addition to having a send,
>>> receive, and transaction history tab in your bitcoin wallet, you'd also
>>> have an open payment channels tab (which would include all applications on
>>> your computer that have an open real time payment channel, such as a wifi
>>> access point, web browser, voip provider, etc.), as well as a "bills to
>>> pay" tab. Since everything would be automated and consolidated locally, you
>>> wouldn't have to deal with logging into a million different websites to get
>>> the bills and then pay them. If it were this easy, why would you ever want
>>> to do a recurring payment from a single payment request? I understand why
>>> you may think you want to given current work flows, but I'm wondering if it
>>> may be better to just skip over to a completely better way of doing things.
>>>
>>>
>>> Andy Schroder
>>>
>>>
>>> On 06/22/2016 11:30 AM, Erik Aronesty wrote:
>>>
>>>> My conclusion at the bottom of that post was to keep BIP 75 the same,
>>>> don't change a bit, and stick any subscription information (future payment
>>>> schedule) in the PaymentACK.   Then the wallet then re-initiates an invoice
>>>> (unattended or attended.. up to the user), after the subscription interval
>>>> is passed. Subscriptions are pretty important for Bitcoin to be used as a
>>>> real payment system.
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 7244 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:
> On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
> Hi Peter,
>    Certainly AML/KYC compliance is one of the use cases that BIP 75 and our
> certificates can support.  As a quick summary,
> 
> There are individuals and entities that would like to buy, sell, and use
> bitcoin, and other public blockchains, but that have compliance
> requirements that they need to meet before they can do so.  Similarly,
> companies and entrepreneurs in the space suffer under the potential threat
> of fines, or in extreme cases, jail time, also for not meeting AML or
> sanctions list compliance.  We wanted to build tools that allowed
> entrepreneurs to breathe easy, while at the same time allow more people and
> companies to enter the ecosystem.  We also believe that the solution we are
> using has the characteristics that you want in such a solution, for example:
> 
> 1> Only the counterparties (and possibly their service providers in the
> case of hosted services) in a transaction can see the identity data,
> protecting user privacy.
> 
> 2> The counterparties themselves (and possibly their service providers in
> the case of hosted services) decide whether identity information is
> required for any given transaction.
> 
> 3> No trace is left on the blockchain or anywhere else (other than with the
> counterparties) that identity information was even exchanged, protecting
> fungibility
> 
> 4> The solution is based on open source and open standards, allowing open
> permissionless innovation, versus parties building closed networks based on
> closed standards.  The very fact that this solution went through the BIP
> process and was adapted based on feedback is an example of how this is
> better for users than the inevitable closed solution that would arise if
> the open source, community vetted version didn’t already exist.
> 
> I don’t know if you are opposed to organizations that have AML requirements
> from using the bitcoin blockchain, but if you aren’t, why wouldn’t you
> prefer an open source, open standards based solution to exclusionary,
> proprietary ones?

In some (most?) countries, it is illegal to offer telecoms services without
wiretap facilities. Does that mean Tor builds into its software "open source"
"open standards" wiretapping functionality? No. And interestingly, people
trying to add support for that stuff is actually a thing that keeps happening
in the Tor community...

In any case, I'd strongly argue that we remove BIP75 from the bips repository,
and boycott wallets that implement it. It's bad strategy for Bitcoin developers
to willingly participate in AML/KYC, just the same way as it's bad for Tor to
add wiretapping functionality, and W3C to support DRM tech. The minor tactical
wins you'll get our of this aren't worth it.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In any case, I'd strongly argue that we remove BIP75 from the bips
repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
developers
> to willingly participate in AML/KYC, just the same way as it's bad for
Tor to
> add wiretapping functionality, and W3C to support DRM tech. The minor
tactical
> wins you'll get our of this aren't worth it.

I hope you're not seriously suggesting to censor a BIP because you feel it
is a bad idea.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 783 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
> > and boycott wallets that implement it. It's bad strategy for Bitcoin
> developers
> > to willingly participate in AML/KYC, just the same way as it's bad for
> Tor to
> > add wiretapping functionality, and W3C to support DRM tech. The minor
> tactical
> > wins you'll get our of this aren't worth it.
> 
> I hope you're not seriously suggesting to censor a BIP because you feel it
> is a bad idea.

For the record, I think the idea of the bips repo being a pure publication
platform isn't a good one and doesn't match reality; like it or not by
accepting bips we're putting a stamp of some kind of approval on them.

For example, I suspect I wouldn't be able to get a BIP for a decentralized
assassination market protocol standard into the repository, regardless of
whether or not it was used - it's simply too distastful and controversial for
us to want to merge that. Would you call that rejection censorship?

I have zero issues with us exercising editorial control over what's in the bips
repo; us doing so doesn't in any way prevent other's from publishing elsewhere.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andreas Schildbach]

On 06/22/2016 04:25 PM, Erik Aronesty via bitcoin-dev wrote:
> 
>     Only large merchants are able to maintain such an infrastructure; (even
>     Coinbase recently failed at it, they forgot to update their
>     certificate). For end users that is completely unpractical.
> 
> 
> Payment protocol is for when you buy stuff from purse.io
> <http://purse.io>, not really needed for face-to face transfers, end
> users, IMO.

What Andy said, plus there is an (unencrypted) version of BIP70 via
Bluetooth already in place. And its used in several thousand
face-to-face trades per day.

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Pieter Wuille]

On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd <pete@petertodd.org> wrote:
> On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
>> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > In any case, I'd strongly argue that we remove BIP75 from the bips
>> repository,
>> > and boycott wallets that implement it. It's bad strategy for Bitcoin
>> developers
>> > to willingly participate in AML/KYC, just the same way as it's bad for
>> Tor to
>> > add wiretapping functionality, and W3C to support DRM tech. The minor
>> tactical
>> > wins you'll get our of this aren't worth it.
>>
>> I hope you're not seriously suggesting to censor a BIP because you feel it
>> is a bad idea.
>
> For the record, I think the idea of the bips repo being a pure publication
> platform isn't a good one and doesn't match reality; like it or not by
> accepting bips we're putting a stamp of some kind of approval on them.

We? I don't feel like I have any authority to say what goes into that
repository, and neither do you. We just give technical opinion on
proposals. The fact that it's under the bitcoin organization on github
is a historical artifact.

> I have zero issues with us exercising editorial control over what's in the bips
> repo; us doing so doesn't in any way prevent other's from publishing elsewhere.

Editorial control is inevitable to some extent, but I think that's
more a matter of process than of opinion. Things like "Was there
community discussion?", "Is it relevant?", "Is there a reference
implementation?". I don't think that you objecting for moral reasons
to an otherwise technically sound idea is a reason for removal of a
BIP. You are of course free to propose alternatives, or recommend
against its usage.

-- 
Pieter

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On Thu, Jun 23, 2016 at 02:01:10PM +0200, Pieter Wuille wrote:
> On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd <pete@petertodd.org> wrote:
> > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
> > For the record, I think the idea of the bips repo being a pure publication
> > platform isn't a good one and doesn't match reality; like it or not by
> > accepting bips we're putting a stamp of some kind of approval on them.
> 
> We? I don't feel like I have any authority to say what goes into that
> repository, and neither do you. We just give technical opinion on
> proposals. The fact that it's under the bitcoin organization on github
> is a historical artifact.

That's simply not how the rest of the community perceives bips, and until we
move them elsewhere that's not going to change.

No matter how much we scream that we don't have authority, the fact of the
matter is the bips are located under the github.com/bitcoin namespace, and we
do have editorial control over them.

> > I have zero issues with us exercising editorial control over what's in the bips
> > repo; us doing so doesn't in any way prevent other's from publishing elsewhere.
> 
> Editorial control is inevitable to some extent, but I think that's
> more a matter of process than of opinion. Things like "Was there
> community discussion?", "Is it relevant?", "Is there a reference
> implementation?". I don't think that you objecting for moral reasons
> to an otherwise technically sound idea is a reason for removal of a
> BIP. You are of course free to propose alternatives, or recommend
> against its usage.

Right, so you accept that we'll exert some degree of editorial control; the
question now is what editorial policies should we exert?

My argument is that rejecting BIP75 is something we should do on
ethical/strategic grounds. You may disagree with that, but please don't troll
and call that "advocating censorship"

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Jun 23, 2016 14:10, "Peter Todd" <pete@petertodd.org> wrote:

> Right, so you accept that we'll exert some degree of editorial control;
the
> question now is what editorial policies should we exert?

No, I do not. I am saying that some degree of editorial control will
inevitably exist, simply because there is some human making the choice of
assigning a BIP number and merging. My opinion is that we should try to
restrict that editorial control to only be subject to objective process,
and not be dependent on personal opinions.

> My argument is that rejecting BIP75 is something we should do on
> ethical/strategic grounds. You may disagree with that, but please don't
troll
> and call that "advocating censorship"

I think that you are free to express dislike of BIP75. Suggesting to remove
it for that reason is utterly ridiculous to me, whatever you want to call
it.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1113 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Thu, Jun 23, 2016 at 02:16:48PM +0200, Pieter Wuille wrote:
> On Jun 23, 2016 14:10, "Peter Todd" <pete@petertodd.org> wrote:
> 
> > Right, so you accept that we'll exert some degree of editorial control;
> the
> > question now is what editorial policies should we exert?
> 
> No, I do not. I am saying that some degree of editorial control will
> inevitably exist, simply because there is some human making the choice of
> assigning a BIP number and merging. My opinion is that we should try to
> restrict that editorial control to only be subject to objective process,
> and not be dependent on personal opinions.
>
> > My argument is that rejecting BIP75 is something we should do on
> > ethical/strategic grounds. You may disagree with that, but please don't
> troll
> > and call that "advocating censorship"
> 
> I think that you are free to express dislike of BIP75. Suggesting to remove
> it for that reason is utterly ridiculous to me, whatever you want to call
> it.

In the future we're likely to see a lot of BIPs around AML/KYC support, e.g.
adding personal identity information to transactions, blacklist standards, etc.
Should we accept those BIPs into the bips repo?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 4534 bytes --]

AML/KYC is a *side-effect *of a some very important features of BIP0075.

Features that have nothing to do with public names for wallet seeds,
and moniker *consistency *should be scrapped.

BIP 75 formalises what someone could do today with a bunch of PGP emails
back and forth.

I create a public key, and I exchange it via QR code with you.   From then
on, You can initiate invoice requests with me, knowing my moniker is the
same as it was the last time.   I publish this key to a server (via DNSSEC)
so anyone can obtain it.   Sounds exactly like PGP.

Identity in BIP 75 is merely "moniker consistency".  Nothing says that
identity has to be "real"... only publicly verifiably consistent and
accessible.  This consistency and the ability to have public names for both
merchants and users are the important features of BIP 075.

Other features linking monikers to real-world identity should be surgically
removed from the standard.

- Users need to be able to send Bitcoin to an address without MITM attacks
during the address exchange.

- Merchants need to be able to supply memorable names linked to internet
services, like web servers and email addresses.

- Merchants and users both need to be able to initiate transaction
off-chain, with a workflow that allows things like rejection, subscription,
etc.



On Thu, Jun 23, 2016 at 6:56 AM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:
> > On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
> > Hi Peter,
> >    Certainly AML/KYC compliance is one of the use cases that BIP 75 and
> our
> > certificates can support.  As a quick summary,
> >
> > There are individuals and entities that would like to buy, sell, and use
> > bitcoin, and other public blockchains, but that have compliance
> > requirements that they need to meet before they can do so.  Similarly,
> > companies and entrepreneurs in the space suffer under the potential
> threat
> > of fines, or in extreme cases, jail time, also for not meeting AML or
> > sanctions list compliance.  We wanted to build tools that allowed
> > entrepreneurs to breathe easy, while at the same time allow more people
> and
> > companies to enter the ecosystem.  We also believe that the solution we
> are
> > using has the characteristics that you want in such a solution, for
> example:
> >
> > 1> Only the counterparties (and possibly their service providers in the
> > case of hosted services) in a transaction can see the identity data,
> > protecting user privacy.
> >
> > 2> The counterparties themselves (and possibly their service providers in
> > the case of hosted services) decide whether identity information is
> > required for any given transaction.
> >
> > 3> No trace is left on the blockchain or anywhere else (other than with
> the
> > counterparties) that identity information was even exchanged, protecting
> > fungibility
> >
> > 4> The solution is based on open source and open standards, allowing open
> > permissionless innovation, versus parties building closed networks based
> on
> > closed standards.  The very fact that this solution went through the BIP
> > process and was adapted based on feedback is an example of how this is
> > better for users than the inevitable closed solution that would arise if
> > the open source, community vetted version didn’t already exist.
> >
> > I don’t know if you are opposed to organizations that have AML
> requirements
> > from using the bitcoin blockchain, but if you aren’t, why wouldn’t you
> > prefer an open source, open standards based solution to exclusionary,
> > proprietary ones?
>
> In some (most?) countries, it is illegal to offer telecoms services without
> wiretap facilities. Does that mean Tor builds into its software "open
> source"
> "open standards" wiretapping functionality? No. And interestingly, people
> trying to add support for that stuff is actually a thing that keeps
> happening
> in the Tor community...
>
> In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
> developers
> to willingly participate in AML/KYC, just the same way as it's bad for Tor
> to
> add wiretapping functionality, and W3C to support DRM tech. The minor
> tactical
> wins you'll get our of this aren't worth it.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 5561 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On Thu, Jun 23, 2016 at 3:56 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
> developers
> to willingly participate in AML/KYC, just the same way as it's bad for Tor
> to
> add wiretapping functionality, and W3C to support DRM tech. The minor
> tactical
> wins you'll get our of this aren't worth it.
>
>
Peter, BIP75 gives the parties transacting complete control over who they
choose to share their identity information with. This was the entire point
of the proposal. You authorize who you choose to give your payment address
to, and the sender can verify who they are sending payment to. All
communication and payment info are encrypted against third party snooping,
while still allowing asynchronous communication to accommodate ephemeral
mobile connections.

The fact that some people will choose to use this identity information for
AML/KYC purposes doesn't detract at all from the fact that it gives bitcoin
users the tools they need to keep their payment information private, and
only communicate it with the parties they choose.

Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com/>

[-- Attachment #2: Type: text/html, Size: 1914 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[s7r]

[-- Attachment #1.1: Type: text/plain, Size: 2056 bytes --]


On 6/23/2016 1:56 PM, Peter Todd via bitcoin-dev wrote:
>>
>> I don’t know if you are opposed to organizations that have AML requirements
>> from using the bitcoin blockchain, but if you aren’t, why wouldn’t you
>> prefer an open source, open standards based solution to exclusionary,
>> proprietary ones?
> 
> In some (most?) countries, it is illegal to offer telecoms services without
> wiretap facilities. Does that mean Tor builds into its software "open source"
> "open standards" wiretapping functionality? No. And interestingly, people
> trying to add support for that stuff is actually a thing that keeps happening
> in the Tor community...
> 
> In any case, I'd strongly argue that we remove BIP75 from the bips repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin developers
> to willingly participate in AML/KYC, just the same way as it's bad for Tor to
> add wiretapping functionality, and W3C to support DRM tech. The minor tactical
> wins you'll get our of this aren't worth it.
> 
Exactly!
Totally agree with Peter Todd. There's absolutely no gain for Bitcoin to
willingly participate in AML/KYC. Plus this might come with strings
attached: for example when running a Tor relay in some countries if you
interfere with the traffic (censor, limit, filter, etc.) you become
responsible for it, while when you only relay anonymous traffic without
interfering or having the possibility to do so (installing certain
tools, using a modified Tor which allows you to do so, etc.) you cannot
be held responsible for the traffic.

Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
expectations from _all_ users from authorities. Companies or individuals
who want and/or need AML/KYC can find ways and do it at their side
isolated from the entire network, and the solutions shouldn't come from
upstream. AML/KYC/<insert other regulation here> differ from country to
country and will be hard to implement in a global consensus network even
if it would be worth it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Justin Newton]

[-- Attachment #1.1: Type: text/plain, Size: 1794 bytes --]

On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
>
> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
> expectations from _all_ users from authorities. Companies or individuals
> who want and/or need AML/KYC can find ways and do it at their side
> isolated from the entire network, and the solutions shouldn't come from
> upstream. AML/KYC/<insert other regulation here> differ from country to
> country and will be hard to implement in a global consensus network even
> if it would be worth it.
>
>
This was precisely our thinking as well.

This is actually exactly why BIP 75 was designed the way that it was.  Any
(voluntary) identity exchange is done at the application level, on an
encrypted https (or other) connection between the sender and receiver.
Identity data is not passed through or stored on the blockchain, and there
is actually no mark left on the blockchain that identity was even exchanged
on that transaction.

The only people who know identity info was exchanged, or what the identity
was is the counterparties in the transaction, and depending on
implementation, their service provider.  (At a high level, many software
based wallet providers wouldn’t have any visibility into identity info,
where many hosted services would, for example)

We did this to protect user privacy as well as fungibility.

We are allowing the people who want or need to exchange identtity info
(either self signed or 3rd party validated) the option to exchange it, in a
standards based way, directly between peers, without touching the
blockchain or network itself.

Is this more clear?

-- 

Justin W. Newton
Founder/CEO
Netki, Inc.

justin@netki.com
+1.818.261.4248

[-- Attachment #1.2: Type: text/html, Size: 3586 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Police Terror]

In England under RIPA 2000 legislation, it's irrelevant whether you have
the data or not. If the authorities compel you to hand over that
information, and it is within your means to obtain it then you are
obliged to do so under threat of criminal offense.

So any mechanism whereby data could be collected from Bitcoin users,
whether it's stored ephemerally or not, if the police have reasonable
suspicion to think it exists then they can compel all parties to work to
get them the data they require.

If the mechanism flat out does not exist, that is miles better than
could exist. Deniability is not a defense when served with a police
notice for disclosing data.

You have to think not only about the end result, but also about how
these mechanisms can be used for intimidating users or leveraging
technologies.

Justin Newton via bitcoin-dev:
> On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>>
>>
>>
>> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
>> expectations from _all_ users from authorities. Companies or individuals
>> who want and/or need AML/KYC can find ways and do it at their side
>> isolated from the entire network, and the solutions shouldn't come from
>> upstream. AML/KYC/<insert other regulation here> differ from country to
>> country and will be hard to implement in a global consensus network even
>> if it would be worth it.
>>
>>
> This was precisely our thinking as well.
> 
> This is actually exactly why BIP 75 was designed the way that it was.  Any
> (voluntary) identity exchange is done at the application level, on an
> encrypted https (or other) connection between the sender and receiver.
> Identity data is not passed through or stored on the blockchain, and there
> is actually no mark left on the blockchain that identity was even exchanged
> on that transaction.
> 
> The only people who know identity info was exchanged, or what the identity
> was is the counterparties in the transaction, and depending on
> implementation, their service provider.  (At a high level, many software
> based wallet providers wouldn’t have any visibility into identity info,
> where many hosted services would, for example)
> 
> We did this to protect user privacy as well as fungibility.
> 
> We are allowing the people who want or need to exchange identtity info
> (either self signed or 3rd party validated) the option to exchange it, in a
> standards based way, directly between peers, without touching the
> blockchain or network itself.
> 
> Is this more clear?
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Justin Newton]

[-- Attachment #1.1: Type: text/plain, Size: 5033 bytes --]

Hi there,
   For users who don’t wish a service provider to be able to see their
information, even ephemerally, and they would like to exchange information
via BIP75, they can use a software wallet, such as a breadwallet or others,
and that data will only exist on their phone, and the phone of their
counterparty (assuming the counterparty also chose to exchange info, and
was running on a software wallet).

In this way, we allow users to exchange data as they choose, without having
the risk that a service provider be asked for that data.

If a user chooses to use a hosted platform, and also to store their
identity data there, I do agree it could be subject to a subpoena, the same
as when they host their email, and other services.

Finally, they could choose not to use BIP75 at all, and no one would know
whether they did or didn’t (other than their counterparts) as we don’t
leave any residue on the blockchain, or anywhere else in the public eye.

We believe that this solution, due in part to its narrow data aperture, is
the best solution available to the problem we are solving.  We are eager to
engage in any discussions about how to improve the proposed solution, with
an eye to fungibility, privacy, and usability.

That said, there is a real need for people to know who they are transacting
with for usability reasons, for fraud reduction, and also of regulatory
reasons for some players.  To NOT solve it with a carefully crafted
standard means that it is more likely to be solved with back room, quick
and dirty solutions that are not available for community review and
feedback.

Thanks!

Justin






On Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In England under RIPA 2000 legislation, it's irrelevant whether you have
> the data or not. If the authorities compel you to hand over that
> information, and it is within your means to obtain it then you are
> obliged to do so under threat of criminal offense.
>
> So any mechanism whereby data could be collected from Bitcoin users,
> whether it's stored ephemerally or not, if the police have reasonable
> suspicion to think it exists then they can compel all parties to work to
> get them the data they require.
>
> If the mechanism flat out does not exist, that is miles better than
> could exist. Deniability is not a defense when served with a police
> notice for disclosing data.
>
> You have to think not only about the end result, but also about how
> these mechanisms can be used for intimidating users or leveraging
> technologies.
>
> Justin Newton via bitcoin-dev:
> > On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >>
> >>
> >>
> >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
> >> expectations from _all_ users from authorities. Companies or individuals
> >> who want and/or need AML/KYC can find ways and do it at their side
> >> isolated from the entire network, and the solutions shouldn't come from
> >> upstream. AML/KYC/<insert other regulation here> differ from country to
> >> country and will be hard to implement in a global consensus network even
> >> if it would be worth it.
> >>
> >>
> > This was precisely our thinking as well.
> >
> > This is actually exactly why BIP 75 was designed the way that it was.
> Any
> > (voluntary) identity exchange is done at the application level, on an
> > encrypted https (or other) connection between the sender and receiver.
> > Identity data is not passed through or stored on the blockchain, and
> there
> > is actually no mark left on the blockchain that identity was even
> exchanged
> > on that transaction.
> >
> > The only people who know identity info was exchanged, or what the
> identity
> > was is the counterparties in the transaction, and depending on
> > implementation, their service provider.  (At a high level, many software
> > based wallet providers wouldn’t have any visibility into identity info,
> > where many hosted services would, for example)
> >
> > We did this to protect user privacy as well as fungibility.
> >
> > We are allowing the people who want or need to exchange identtity info
> > (either self signed or 3rd party validated) the option to exchange it,
> in a
> > standards based way, directly between peers, without touching the
> > blockchain or network itself.
> >
> > Is this more clear?
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > 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
>



-- 

Justin W. Newton
Founder/CEO
Netki, Inc.

justin@netki.com
+1.818.261.4248

[-- Attachment #1.2: Type: text/html, Size: 7696 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Erik Aronesty]

[-- Attachment #1.1: Type: text/plain, Size: 5742 bytes --]

Sometimes I think there's concerted resistance to making Bitcoin usable for
the average person.   Clearly the primary purpose of BIP0075 is to enshrine
a DNSSEC protocol for giving wallet addresses memorable names.


On Thu, Jun 23, 2016 at 6:44 PM, Justin Newton via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi there,
>    For users who don’t wish a service provider to be able to see their
> information, even ephemerally, and they would like to exchange information
> via BIP75, they can use a software wallet, such as a breadwallet or others,
> and that data will only exist on their phone, and the phone of their
> counterparty (assuming the counterparty also chose to exchange info, and
> was running on a software wallet).
>
> In this way, we allow users to exchange data as they choose, without
> having the risk that a service provider be asked for that data.
>
> If a user chooses to use a hosted platform, and also to store their
> identity data there, I do agree it could be subject to a subpoena, the same
> as when they host their email, and other services.
>
> Finally, they could choose not to use BIP75 at all, and no one would know
> whether they did or didn’t (other than their counterparts) as we don’t
> leave any residue on the blockchain, or anywhere else in the public eye.
>
> We believe that this solution, due in part to its narrow data aperture, is
> the best solution available to the problem we are solving.  We are eager to
> engage in any discussions about how to improve the proposed solution, with
> an eye to fungibility, privacy, and usability.
>
> That said, there is a real need for people to know who they are
> transacting with for usability reasons, for fraud reduction, and also of
> regulatory reasons for some players.  To NOT solve it with a carefully
> crafted standard means that it is more likely to be solved with back room,
> quick and dirty solutions that are not available for community review and
> feedback.
>
> Thanks!
>
> Justin
>
>
>
>
>
>
> On Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> In England under RIPA 2000 legislation, it's irrelevant whether you have
>> the data or not. If the authorities compel you to hand over that
>> information, and it is within your means to obtain it then you are
>> obliged to do so under threat of criminal offense.
>>
>> So any mechanism whereby data could be collected from Bitcoin users,
>> whether it's stored ephemerally or not, if the police have reasonable
>> suspicion to think it exists then they can compel all parties to work to
>> get them the data they require.
>>
>> If the mechanism flat out does not exist, that is miles better than
>> could exist. Deniability is not a defense when served with a police
>> notice for disclosing data.
>>
>> You have to think not only about the end result, but also about how
>> these mechanisms can be used for intimidating users or leveraging
>> technologies.
>>
>> Justin Newton via bitcoin-dev:
>> > On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> >>
>> >>
>> >>
>> >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
>> >> expectations from _all_ users from authorities. Companies or
>> individuals
>> >> who want and/or need AML/KYC can find ways and do it at their side
>> >> isolated from the entire network, and the solutions shouldn't come from
>> >> upstream. AML/KYC/<insert other regulation here> differ from country to
>> >> country and will be hard to implement in a global consensus network
>> even
>> >> if it would be worth it.
>> >>
>> >>
>> > This was precisely our thinking as well.
>> >
>> > This is actually exactly why BIP 75 was designed the way that it was.
>> Any
>> > (voluntary) identity exchange is done at the application level, on an
>> > encrypted https (or other) connection between the sender and receiver.
>> > Identity data is not passed through or stored on the blockchain, and
>> there
>> > is actually no mark left on the blockchain that identity was even
>> exchanged
>> > on that transaction.
>> >
>> > The only people who know identity info was exchanged, or what the
>> identity
>> > was is the counterparties in the transaction, and depending on
>> > implementation, their service provider.  (At a high level, many software
>> > based wallet providers wouldn’t have any visibility into identity info,
>> > where many hosted services would, for example)
>> >
>> > We did this to protect user privacy as well as fungibility.
>> >
>> > We are allowing the people who want or need to exchange identtity info
>> > (either self signed or 3rd party validated) the option to exchange it,
>> in a
>> > standards based way, directly between peers, without touching the
>> > blockchain or network itself.
>> >
>> > Is this more clear?
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > 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
>>
>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin@netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #1.2: Type: text/html, Size: 8764 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte]

[-- Attachment #1.1: Type: text/plain, Size: 629 bytes --]

> Clearly the primary purpose of BIP0075 is to enshrine a DNSSEC protocol
> for giving wallet addresses memorable names.
>
>
I can't tell if you're being sarcastic or not, but if you aren't, I don't
think this is an accurate description at all. BIP75 is, at its most
simplest, nothing more than an encrypted/encapsulated version of BIP70. All
we did was make it safe for people to exchange BIP70 messages through an
intermediary.

The only identity information included in BIP75 is the pki_data field,
which wasn't even introduced in BIP75--it was already in BIP70. I'm
guessing Peter would also have us remove BIP70 altogether?

[-- Attachment #1.2: Type: text/html, Size: 913 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]