Re: [Bitcoin-development] Proposed BIP 70 extension
I agree. It would be even sillier to start specifying container formats for random one-off that would be kind of nice, I guess features. No, it'd be sensible. Here's a list I drew up a long time ago of features I imagined adding to the payment protocol: https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147 The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. The shared resource in question is just varint encoded integers. So, we should be guided by what will help our users and what will help adoption. Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago. I want to use something simple to set up the extensions process more formally. IMO we need a living document version of the payment protocol with all the different extensions out there folded into it, to simplify programming tasks and ensure field numbers don't collide. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension
I'm not convinced this inversion is really a problem, but as this is quite
a complex proposal (e.g. new barcode types) the best way to move it forward
at this stage is to implement it in some existing wallets.
FWIW NFC is a lot more common than you might think. For the drive-thru case
you could also consider using wifi hotspots with a special name or
Bluetooth LE tags. So I suspect before trying to write a specification it'd
be better to explore different technologies and see what works best in
practice.
On Tue, Jun 24, 2014 at 9:44 PM, Paul Goldstein p...@realfoot.com wrote:
Here's an idea for a BIP 70 extension to let wallets be scanned by
merchant bar code readers to start off a payment request flow instead of
the other way around (wallet scanning the merchant QR). Useful for brick
and mortar merchants and mobile wallet apps.
Motivation:
A mechanism is needed for mobile wallets to request a bill, so that a
payment protocol flow can be initiated. Current mechanisms for initiating
BIP70 payment flows generally require wallets to either scan a merchant
barcode (not optimal, see below), or click on a specially formatted url
link (only suitable while browsing and purchasing on a merchant website).
Successful non-bitcoin mobile wallet apps to date (a popular coffee shop
app comes to mind) allow for the wallet app to be scanned by the merchant
and not the other way around (as is commonly done in bitcoin wallets
today). For broad bitcoin adoption we need a mechanism for wallets to be
scanned by merchant bar code readers at brick and mortar shops. This will
also greatly ease checkouts at drive throughs and allows merchants to
leverage existing hardware (barcode readers).
Other technologies like NFC may obviate the need for this extension,
however, those technologies remain somewhat uncommon and may not be
suitable for smaller wearables hitting the market.
message BillRequest {
required uint64 time = 1;
optional uint64 expires = 2;
required string bill_request_uri = 3;
}
time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest
was created.
expires - Unix timestamp (UTC) after which the BillRequest should be
considered invalid (wallets may only be monitoring for messages for a short
time).
bill_req_addr - Typically a URL where a BIP70 payment request can be sent
that is being monitored by the wallet. However this could also support URIs
like sms:860-555-1212 or mailto:a...@gmail.com; allowing for a variety
of connection options.
Recommendations: it is recommended that wallet apps display a non-QR
barcode like a PDF417 barcode to initiate the Bill Request flow. This will
avoid confusion with existing QR code usage in wallet apps.
Paul G.
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
+1 on setting up the payment protocol extensions process more formally. On the feature itself, it is interesting to note that some complementary currencies backed by national currencies offer a discount when converting from fiat to complementary, which has an equivalent effect to this discount for paying with btc. The main difference is that in local currencies the merchants are a relatively small group and the discount is uniform whereas here each merchant can set his own discount. There's scientific studies on how different currency features like these discounts affect adoption, velocity and other variables. I can ask for them if anyone is interested. On the implementation, I think a percentage/proportion would be preferable over an amount in satoshis. Let's imagine for a second that the bitcoin payment protocol ends up being a generalized and universal payment protocol. The field would be really something like discount/additional_charge for paying with the chosen currency/payment_method. You could have 0.95 for a 5% discount or 1.05 for a 5% additional charge. Mhmm, maybe a flat discount/charge in addition to the proportional one... On security, being an optional field, I don't see how can it harm anything. It is true that the merchants can lie about the discount, but wallets can be smart or stupid about it, or just completely ignore the field as they wish. Anyway, it feels like a random simple extension as an excuse to develop the extension process. If it gets too complicated we can start with a simpler and less critical one but it's hard for me to imagine it. On 6/25/14, Mike Hearn m...@plan99.net wrote: I agree. It would be even sillier to start specifying container formats for random one-off that would be kind of nice, I guess features. No, it'd be sensible. Here's a list I drew up a long time ago of features I imagined adding to the payment protocol: https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147 The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. The shared resource in question is just varint encoded integers. So, we should be guided by what will help our users and what will help adoption. Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago. I want to use something simple to set up the extensions process more formally. IMO we need a living document version of the payment protocol with all the different extensions out there folded into it, to simplify programming tasks and ensure field numbers don't collide. -- Jorge Timón -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum lawre...@greenaddress.it wrote: [snip] Allow me to recap BIP changes in discussion: - making some changes to allow merchants to offer discounts in case of instant ? - allowing multiple signatures ? Did I miss anything? Thoughts on the above from others? Jumping on this thread after reading it all. I am in favor of the discount offered by the merchant. Ideally the merchant could get the amount of the wallet *fee* for instant payment (privacy leak?). That way, the merchant could decide to support the instant payment at 100% (better user experience after all) or at 50% only or at 0%. This would encourage instant payment for merchants and buyers without (re-)creating a non-transparent system. regards, -- sebastien requiem - bendingspoons.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn m...@plan99.net wrote: The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields. HTTP status codes are good example. There are hundreds of them, still applications understands just few of them, because other have ambiguous meaning and software don't know how to handle them. Good example of such over-engineering is also XMPP. XMPP has milions extensions and features, but look at Jabber clients; call yourself lucky when you can send messages and files, although there're various extensions like searching for contacts (something which has be working in ICQ decade ago), voice support, end to end encryption or alerting users. These features are defined, but not widely implemented, because its definition is vague or the feature is abused because of poor design. Please don't over-engineer payment protocol. Thank you for your attention. slush -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension
Alright. I still tend to think it's not a big deal, but there's no reason both or all mechanisms can't co-exist. BTW: a QR code next to a cash register can be fixed i.e. printed on paper when using BIP70. The PoS would upload payment details to the server and the URL for that particular PoS unit would then serve it when the user scans the QR code. Alternatively, Andreas' work on Bluetooth may be more appropriate: the QR code can contain the BT MAC of the device and the payment request is downloaded that way. That's already implemented! I still feel that if a seller can scan a users phone, the users phone can certainly scan some rectangle that's physically near by the sales counter. The other nice thing about that approach is the QRcode can also be an NFC tag i.e. have the tag behind it with a little icon in the middle of the QR code to indicate that touching works as well as scanning. One project I keep wanting to play with is making these little NFC-QRcode hybrids and a simple PoS app to go with them. But no time, alas -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Wallet nLockTime best practices
I'm inclined to merge https://github.com/bitcoin/bitcoin/pull/2340 which sets nLockTime on wallet-created transactions by default. I think this is good practice for wallets, long term. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
On Jun 25, 2014, at 10:15, slush sl...@centrum.cz wrote: Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields. +1. BIP70 is important. We want to keep it very simple and generalized, or there is a very real risk that implementers will either not bother with it or implement it in buggy, poorly standardized ways. Any information not required by the machine should only exist in human-oriented fields (namely, the memo field). Let's try to avoid ending up with another horrendously complicated, edge-case-oriented protocol like we programmers frequently complain about. smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP 70 extension
Remember the IETF RFC process. 1) RFCs are never updated. Extensions go into new RFCs. 2) Build an implementation, write a draft, circulate both. Then get a BIP number. 3) As MH indicated, it would be useful to have a living payment protocol document that _is_ updated. 4) Let's stop calling it BIP70. That just reinforces the desire to update the BIP70 document. On Wed, Jun 25, 2014 at 9:33 AM, Jorge Timón jti...@monetize.io wrote: +1 on setting up the payment protocol extensions process more formally. On the feature itself, it is interesting to note that some complementary currencies backed by national currencies offer a discount when converting from fiat to complementary, which has an equivalent effect to this discount for paying with btc. The main difference is that in local currencies the merchants are a relatively small group and the discount is uniform whereas here each merchant can set his own discount. There's scientific studies on how different currency features like these discounts affect adoption, velocity and other variables. I can ask for them if anyone is interested. On the implementation, I think a percentage/proportion would be preferable over an amount in satoshis. Let's imagine for a second that the bitcoin payment protocol ends up being a generalized and universal payment protocol. The field would be really something like discount/additional_charge for paying with the chosen currency/payment_method. You could have 0.95 for a 5% discount or 1.05 for a 5% additional charge. Mhmm, maybe a flat discount/charge in addition to the proportional one... On security, being an optional field, I don't see how can it harm anything. It is true that the merchants can lie about the discount, but wallets can be smart or stupid about it, or just completely ignore the field as they wish. Anyway, it feels like a random simple extension as an excuse to develop the extension process. If it gets too complicated we can start with a simpler and less critical one but it's hard for me to imagine it. On 6/25/14, Mike Hearn m...@plan99.net wrote: I agree. It would be even sillier to start specifying container formats for random one-off that would be kind of nice, I guess features. No, it'd be sensible. Here's a list I drew up a long time ago of features I imagined adding to the payment protocol: https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147 The protocol is there to contain features! There is zero benefit to slavishly following some religious notion of purity or minimalism here. The shared resource in question is just varint encoded integers. So, we should be guided by what will help our users and what will help adoption. Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago. I want to use something simple to set up the extensions process more formally. IMO we need a living document version of the payment protocol with all the different extensions out there folded into it, to simplify programming tasks and ensure field numbers don't collide. -- Jorge Timón -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
