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:
+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 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
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
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@plan99.net wrote:
Wallets would then be able to persist this data to disk and compete on cool
visualisations for how much money you saved over time.
heh, this is a cool idea.
It also seems like it would be subject to instant inflation, as it's
It also seems like it would be subject to instant inflation, as it's
unprovable
The user knows the price that is on the website or menu, they know the
price they actually paid ... if the numbers don't add up that would seem to
be pretty easily detectable. But sure it's only for marketing. I
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.
Payment protocol should not contain these fictional data, which has no real
meaning for the
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.
Your own wallet can look up the exchange rate and compare it to what you're
getting (and
On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote:
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that the
merchant cut you on BTC/USD exchange rate in tens of %.
People would also abuse
I think it should be made more clear what's the reference price for the
discount. In Germany, we generally don't use credit cards but rather
EC-Cards, which is already much cheaper. Or maybe for some merchants
the only alternative is cash, and they would still offer a Bitcoin discount.
Also,
I think there is nothing wrong with having a numeric memo field, which
is effectively what this is. Structured rather than unstructured
data.
On Tue, Jun 24, 2014 at 11:15 AM, Gmail will.ya...@gmail.com wrote:
On Jun 24, 2014, at 10:32, slush sl...@centrum.cz wrote:
Sounds like marketing
I think it should be made more clear what's the reference price for the
discount.
That might be useful for merchants that already provide a series of
price-differentiated payment methods, yes. Will think about it.
Also, currently PR are created by the payment processors afaik. How can
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn m...@plan99.net wrote:
Coinbase have started allowing merchants to set discounts for purchasing
with Bitcoin. Seeing an individual discount is not very motivating as they
tend to be small. Seeing them stack up over time can be more
Ok, wanting structured data is a decent argument, but why this random arbitrary
case in particular? There are hundreds of fields like this that people might
want to use.
If we're going to support one random cosmetic field, we might as well support
them all with a generic structured data
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn m...@plan99.net wrote:
Wallets would then be able to persist this data to disk and compete on cool
visualisations for how much money you saved over time.
heh, this is a cool idea.
I somewhat agree with Will (but also with Mike, Jeff, and Charlie.) I
think the idea of letting consumers know advanced details about the
transaction is good and defining these with strong types is also good.
Maybe an arbitrary set of accounting line items would be more
palatable. You could have a
On Tue, Jun 24, 2014 at 3:00 PM, Gmail will.ya...@gmail.com wrote:
Ok, wanting structured data is a decent argument, but why this random
arbitrary case in particular? There are hundreds of fields like this that
people might want to use.
Protocol buffers are designed to be extensible, and
On Jun 24, 2014, at 16:12, Gavin Andresen gavinandre...@gmail.com wrote:
It would be silly to add a generic stuff field inside a container format
that ALREADY has all the mechanisms necessary for forwards and backwards
extensibility.
I agree. It would be even sillier to start specifying
19 matches
Mail list logo
