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 mercha

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

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 j

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 int

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

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

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

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 trans

[bitcoin-dev] Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance

At the recent coredev.tech meetup in Zurich I spent much of my time discussing anti-censorship improvements with Adam Back, building on his idea of blind symmetric commitments[^bsc], and my own ideas of client-side verification. Our goal here is to combat censorship by ensuring that miners do not h

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