Discussion:
Even more proposed BIP extensions to BIP 0070
(too old to reply)
Erik Aronesty via bitcoin-dev
2016-06-20 17:33:32 UTC
Permalink
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
Andreas Schildbach via bitcoin-dev
2016-06-21 09:43:15 UTC
Permalink
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.
Post by Erik Aronesty via bitcoin-dev
- 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.
/
- 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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2016-06-21 17:09:41 UTC
Permalink
On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
Post by Andreas Schildbach via bitcoin-dev
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.
Post by Andreas Schildbach via bitcoin-dev
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.
Andy Schroder via bitcoin-dev
2016-06-21 19:50:59 UTC
Permalink
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
Post by Andreas Schildbach via bitcoin-dev
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.
Post by Erik Aronesty via bitcoin-dev
- 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.
/
- 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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Luke Dashjr via bitcoin-dev
2016-06-21 20:44:37 UTC
Permalink
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Erik Aronesty via bitcoin-dev
- 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).
Post by Erik Aronesty via bitcoin-dev
- missing an optional client supplied identification
What do you mean by this? There's the memo field at least.
Post by Erik Aronesty via bitcoin-dev
- 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?
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Erik Aronesty via bitcoin-dev
*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
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
Erik Aronesty via bitcoin-dev
2016-06-21 21:42:39 UTC
Permalink
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.
Post by Erik Aronesty via bitcoin-dev
- protocol buffers are inappropriate since ease of use and extensibility
is
Post by Erik Aronesty via bitcoin-dev
desired over the minor gains of efficiency in this protocol. Not too
late
Post by Erik Aronesty via bitcoin-dev
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.
Post by Erik Aronesty via bitcoin-dev
- 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
Post by Erik Aronesty via bitcoin-dev
there is no reliance on the existing domain-name system (you can sell
with
Post by Erik Aronesty via bitcoin-dev
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).
Post by Erik Aronesty via bitcoin-dev
- missing an optional client supplied identification
What do you mean by this? There's the memo field at least.
Post by Erik Aronesty via bitcoin-dev
- 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?
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Erik Aronesty via bitcoin-dev
*Proposed in general:*
- JSON should be used instead of protocol buffers going forward. Easier
to
Post by Erik Aronesty via bitcoin-dev
use, explain extend.
- "Extendible" URI-like scheme to support multi-mode identity mechanisms
on
Post by Erik Aronesty via bitcoin-dev
both payment and subscription requests. Support for keybase://,
netki://
Post by Erik Aronesty via bitcoin-dev
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
Should this be a new BIP? I know netki's BIP75 is out there - but I
think
Post by Erik Aronesty via bitcoin-dev
it's too specific and too reliant on the domain name system.
Maybe an identity-protocol-agnostic BIP + solid implementation of a
couple
Post by Erik Aronesty via bitcoin-dev
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,
Post by Erik Aronesty via bitcoin-dev
is enough - or is it always better to have an extensible protocol?
- Erik Aronesty
Luke Dashjr via bitcoin-dev
2016-06-22 00:36:53 UTC
Permalink
Post by Erik Aronesty via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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?
Post by Erik Aronesty via bitcoin-dev
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. ;)
Post by Erik Aronesty via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-06-21 22:10:08 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
- 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
Peter Todd via bitcoin-dev
2016-06-21 22:19:40 UTC
Permalink
Post by Luke Dashjr via bitcoin-dev
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
James MacWhyte via bitcoin-dev
2016-06-21 20:56:40 UTC
Permalink
Thanks for starting this discussion, Erik.
Post by Erik Aronesty via bitcoin-dev
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
Matt David via bitcoin-dev
2016-06-21 21:17:12 UTC
Permalink
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.
Post by James MacWhyte via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter Todd via bitcoin-dev
2016-06-21 22:13:47 UTC
Permalink
Post by Erik Aronesty via bitcoin-dev
- 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
James MacWhyte via bitcoin-dev
2016-06-21 22:50:36 UTC
Permalink
Post by Peter Todd via bitcoin-dev
Note that "client supplied identification" is being pushed for AML/KYC
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.
Peter Todd via bitcoin-dev
2016-06-21 23:02:33 UTC
Permalink
Post by James MacWhyte via bitcoin-dev
Post by Peter Todd via bitcoin-dev
Note that "client supplied identification" is being pushed for AML/KYC
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
Justin Newton via bitcoin-dev
2016-06-22 00:14:31 UTC
Permalink
On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
Post by Peter Todd via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
- missing an optional client supplied identification
Note that "client supplied identification" is being pushed for AML/KYC
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.

***@netki.com
+1.818.261.4248
Peter Todd via bitcoin-dev
2016-06-23 10:56:32 UTC
Permalink
Post by Justin Newton via bitcoin-dev
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
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
Pieter Wuille via bitcoin-dev
2016-06-23 11:30:45 UTC
Permalink
On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
Post by Peter Todd via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-06-23 11:39:04 UTC
Permalink
Post by Pieter Wuille via bitcoin-dev
On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
Post by Peter Todd via bitcoin-dev
In any case, I'd strongly argue that we remove BIP75 from the bips
repository,
Post by Peter Todd via bitcoin-dev
and boycott wallets that implement it. It's bad strategy for Bitcoin
developers
Post by Peter Todd via bitcoin-dev
to willingly participate in AML/KYC, just the same way as it's bad for
Tor to
Post by Peter Todd via bitcoin-dev
add wiretapping functionality, and W3C to support DRM tech. The minor
tactical
Post by Peter Todd via bitcoin-dev
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
Pieter Wuille via bitcoin-dev
2016-06-23 12:01:10 UTC
Permalink
Post by Peter Todd via bitcoin-dev
Post by Pieter Wuille via bitcoin-dev
On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
Post by Peter Todd via bitcoin-dev
In any case, I'd strongly argue that we remove BIP75 from the bips
repository,
Post by Peter Todd via bitcoin-dev
and boycott wallets that implement it. It's bad strategy for Bitcoin
developers
Post by Peter Todd via bitcoin-dev
to willingly participate in AML/KYC, just the same way as it's bad for
Tor to
Post by Peter Todd via bitcoin-dev
add wiretapping functionality, and W3C to support DRM tech. The minor
tactical
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-06-23 12:10:00 UTC
Permalink
Post by Pieter Wuille via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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.
Post by Pieter Wuille via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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
Pieter Wuille via bitcoin-dev
2016-06-23 12:16:48 UTC
Permalink
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-06-23 12:43:04 UTC
Permalink
Post by Pieter Wuille via bitcoin-dev
Post by Peter Todd via bitcoin-dev
Right, so you accept that we'll exert some degree of editorial control;
the
Post by Peter Todd via bitcoin-dev
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.
Post by Peter Todd via bitcoin-dev
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
Post by Peter Todd via bitcoin-dev
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
Erik Aronesty via bitcoin-dev
2016-06-23 13:03:36 UTC
Permalink
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.
Post by Justin Newton via bitcoin-dev
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
companies to enter the ecosystem. We also believe that the solution we
are
Post by Justin Newton via bitcoin-dev
using has the characteristics that you want in such a solution, for
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
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
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.
--
Aaron Voisine via bitcoin-dev
2016-06-23 16:58:58 UTC
Permalink
On Thu, Jun 23, 2016 at 3:56 AM, Peter Todd via bitcoin-dev <
Post by Peter Todd via bitcoin-dev
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/>
s7r via bitcoin-dev
2016-06-23 20:46:46 UTC
Permalink
Post by Peter Todd via bitcoin-dev
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.
Justin Newton via bitcoin-dev
2016-06-23 21:07:06 UTC
Permalink
On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
Post by s7r via bitcoin-dev
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.

***@netki.com
+1.818.261.4248
Police Terror via bitcoin-dev
2016-06-23 21:31:29 UTC
Permalink
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.
Post by Justin Newton via bitcoin-dev
On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
Post by s7r via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Justin Newton via bitcoin-dev
2016-06-23 22:44:34 UTC
Permalink
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 <
Post by Police Terror via bitcoin-dev
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.
Post by Justin Newton via bitcoin-dev
On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
Post by s7r via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
(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
Post by Justin Newton via bitcoin-dev
is actually no mark left on the blockchain that identity was even
exchanged
Post by Justin Newton via bitcoin-dev
on that transaction.
The only people who know identity info was exchanged, or what the
identity
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
standards based way, directly between peers, without touching the
blockchain or network itself.
Is this more clear?
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Justin W. Newton
Founder/CEO
Netki, Inc.

***@netki.com
+1.818.261.4248
Erik Aronesty via bitcoin-dev
2016-06-24 02:26:52 UTC
Permalink
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 <
Post by Justin Newton via bitcoin-dev
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 <
Post by Police Terror via bitcoin-dev
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.
Post by Justin Newton via bitcoin-dev
On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
Post by s7r via bitcoin-dev
Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
expectations from _all_ users from authorities. Companies or
individuals
Post by Justin Newton via bitcoin-dev
Post by s7r via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
Post by s7r via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
(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
Post by Justin Newton via bitcoin-dev
is actually no mark left on the blockchain that identity was even
exchanged
Post by Justin Newton via bitcoin-dev
on that transaction.
The only people who know identity info was exchanged, or what the
identity
Post by Justin Newton via bitcoin-dev
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
Post by Justin Newton via bitcoin-dev
standards based way, directly between peers, without touching the
blockchain or network itself.
Is this more clear?
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
James MacWhyte via bitcoin-dev
2016-06-24 05:27:36 UTC
Permalink
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?

Thomas Voegtlin via bitcoin-dev
2016-06-22 07:57:37 UTC
Permalink
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.
Post by Erik Aronesty via bitcoin-dev
- 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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2016-06-22 14:25:03 UTC
Permalink
Post by Thomas Voegtlin via bitcoin-dev
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.
Post by Thomas Voegtlin via bitcoin-dev
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.
Post by Thomas Voegtlin via bitcoin-dev
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.
Andy Schroder via bitcoin-dev
2016-06-22 15:12:04 UTC
Permalink
Post by Thomas Voegtlin via bitcoin-dev
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).
Post by Thomas Voegtlin via bitcoin-dev
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.
Post by Thomas Voegtlin via bitcoin-dev
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.
Post by Thomas Voegtlin via bitcoin-dev
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?
Erik Aronesty via bitcoin-dev
2016-06-22 15:30:55 UTC
Permalink
Post by Andy Schroder via bitcoin-dev
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.


​
Andy Schroder via bitcoin-dev
2016-06-22 16:20:38 UTC
Permalink
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
Post by Erik Aronesty via bitcoin-dev
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.
Erik Aronesty via bitcoin-dev
2016-06-22 17:07:21 UTC
Permalink
- 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.
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
Post by Erik Aronesty via bitcoin-dev
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.
James MacWhyte via bitcoin-dev
2016-06-22 20:11:36 UTC
Permalink
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 <
Post by Erik Aronesty via bitcoin-dev
- 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.
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
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2016-06-22 20:37:06 UTC
Permalink
Post by James MacWhyte via bitcoin-dev
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.
Post by James MacWhyte via bitcoin-dev
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 <
Post by Erik Aronesty via bitcoin-dev
- 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.
Post by Andy Schroder via bitcoin-dev
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
Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Andreas Schildbach via bitcoin-dev
2016-06-23 11:50:16 UTC
Permalink
Post by Thomas Voegtlin via bitcoin-dev
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.
Loading...