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 B
> On Jun 25, 2014, at 10:15, slush 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 ri
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn 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
+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
>
> 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.ph
> On Jun 24, 2014, at 16:12, Gavin Andresen 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 container formats
On Tue, Jun 24, 2014 at 3:00 PM, Gmail 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 there are hundreds o
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 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn 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
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 format
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn 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 motivating
> be
>
> 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
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 wrote:
>
>
>> On Jun 24, 2014, at 10:32, slush wrote:
>>
>> Sounds like marketing bullshit to me. It does not hav
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, cur
> On Jun 24, 2014, at 10:32, slush 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 this feature
>
> 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
gettin
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
>
> 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.
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn 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
unprovable, an
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 motivating
because it feels like free money. Many businesses exploit this effect with
loya
20 matches
Mail list logo