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

> 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

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

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 <

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

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

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

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

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

On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw > expectations from _all_ users from authorities. Companies or individuals > who want and/or need AML/KYC can find ways

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

On 6/23/2016 1:56 PM, Peter Todd via bitcoin-dev wrote: >> >> I don’t know if you are opposed to organizations that have AML requirements >> from using the bitcoin blockchain, but if you aren’t, why wouldn’t you >> prefer an open source, open standards based solution to exclusionary, >>

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

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

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

On Thu, Jun 23, 2016 at 02:16:48PM +0200, Pieter Wuille wrote: > On Jun 23, 2016 14:10, "Peter Todd" wrote: > > > Right, so you accept that we'll exert some degree of editorial control; > the > > question now is what editorial policies should we exert? > > No, I do not. I am

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

On Jun 23, 2016 14:10, "Peter Todd" wrote: > Right, so you accept that we'll exert some degree of editorial control; the > question now is what editorial policies should we exert? No, I do not. I am saying that some degree of editorial control will inevitably exist, simply

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

On Thu, Jun 23, 2016 at 02:01:10PM +0200, Pieter Wuille wrote: > On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd wrote: > > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: > > For the record, I think the idea of the bips repo being a pure publication > > platform

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

On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd wrote: > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: >> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> > In any case, I'd strongly argue that we remove

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

On 06/22/2016 04:25 PM, Erik Aronesty via bitcoin-dev wrote: > > Only large merchants are able to maintain such an infrastructure; (even > Coinbase recently failed at it, they forgot to update their > certificate). For end users that is completely unpractical. > > > Payment protocol

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

On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: > On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, > > and boycott wallets that implement it.

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

On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > In any case, I'd strongly argue that we remove BIP75 from the bips repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin developers > to willingly participate in

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

On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote: > On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < > Hi Peter, >Certainly AML/KYC compliance is one of the use cases that BIP 75 and our > certificates can support. As a quick summary, > > There are individuals and

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

> 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

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

- 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

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

> 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

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

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

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

> 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

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

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

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

On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote: > > What do you mean by "replacement addresses" and "UI confirms" here? > > "Replacement addresses" would take the place of BIP 32/47 support, if > someone thought maybe that was too difficult to deal with. So each time i > paid Alice,

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

On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Jun 20, 2016 at 05:33:32PM +, Erik Aronesty via bitcoin-dev > wrote: > > > - missing an optional client supplied identification > > Note that "client supplied identification"

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

On Tue, Jun 21, 2016 at 10:50:36PM +, James MacWhyte wrote: > > Note that "client supplied identification" is being pushed for AML/KYC > > compliance, e.g. Netki's AML/KYC compliance product: > > > > > >

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

> 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

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

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

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

On Mon, Jun 20, 2016 at 05:33:32PM +, Erik Aronesty via bitcoin-dev wrote: > BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility is > desired over the minor gains of efficiency in this protocol. Not too late > to

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

On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote: > On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > > BIP 0070 has been a a moderate success, however, IMO: > > > > - protocol buffers are inappropriate since ease of use and extensibility is > >

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

> 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

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

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

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

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

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

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

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

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

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

On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen > because of its strong types, less vulnerability to malleability and very > good platform support. Having

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

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

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

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