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:
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
+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
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
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
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
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/
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
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
9 matches
Mail list logo
