Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:Looking good! I think this ...
📅 Original date posted:2014-06-16
📝 Original message:Looking good! I think this is much better than the original draft. Agree
with Andreas that supports_instant is simply equal to
(supported_instant_providers.size() > 1) which makes it redundant.
Daniel is right that putting every possible provider in the Payment message
might not scale in a world where there are huge numbers of
instant-confirmation providers, but I'm hoping that we never have to scale
to that size, because if we did that'd rather imply that Bitcoin has become
useless for in-person payments without trusted third parties and avoiding
that is rather the whole point of the project :) So I'm OK with some
theoretical lack of scalability for now.
A more scalable approach would be for the user to send the name and
signature of their "instant provider" every time and the merchant just
chooses whether to ignore it or not, but as Lawrence points out, this is
incompatible with the provider charging extra fees for "instantness". But
should we care? I'm trying to imagine what the purchasing experience is
like with optional paid-for third party anti-double-spend protection.
Ultimately it's the merchant who cares about this, not me, so why would I
ever pay? It makes no sense for me to pay for double spend protection for
the merchant: after all, I'm honest. This is why it doesn't make sense for
me to pay miners fees either, it's the *receiver* who cares about
confirmations, not the sender.
So I wonder if a smarter design is that the user always submits the details
of their instantness provider and we just don't allow for optional
selection of instantness. I'm not sure that works, UX wise, so is having a
less scalable design to support it worthwhile?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/3b7fc1e0/attachment.html>;
📝 Original message:Looking good! I think this is much better than the original draft. Agree
with Andreas that supports_instant is simply equal to
(supported_instant_providers.size() > 1) which makes it redundant.
Daniel is right that putting every possible provider in the Payment message
might not scale in a world where there are huge numbers of
instant-confirmation providers, but I'm hoping that we never have to scale
to that size, because if we did that'd rather imply that Bitcoin has become
useless for in-person payments without trusted third parties and avoiding
that is rather the whole point of the project :) So I'm OK with some
theoretical lack of scalability for now.
A more scalable approach would be for the user to send the name and
signature of their "instant provider" every time and the merchant just
chooses whether to ignore it or not, but as Lawrence points out, this is
incompatible with the provider charging extra fees for "instantness". But
should we care? I'm trying to imagine what the purchasing experience is
like with optional paid-for third party anti-double-spend protection.
Ultimately it's the merchant who cares about this, not me, so why would I
ever pay? It makes no sense for me to pay for double spend protection for
the merchant: after all, I'm honest. This is why it doesn't make sense for
me to pay miners fees either, it's the *receiver* who cares about
confirmations, not the sender.
So I wonder if a smarter design is that the user always submits the details
of their instantness provider and we just don't allow for optional
selection of instantness. I'm not sure that works, UX wise, so is having a
less scalable design to support it worthwhile?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/3b7fc1e0/attachment.html>;