Daniel Rice [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:Mike Hearn <mike at ...
📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike at plan99.net> wrote:
>> 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?
Lawrence Nahum <lawrence at greenaddress.it> wrote:
> I think you are wrong here.
> Just because up to date credit cards charged the merchant which in turn
> charged you and the ordinary cash payer doesn't mean a newer and better
> system can't be transparent from day one.
I don't think a whitelist of trust is a practical approach because you are
going to want to have varying levels of trust in different instant
providers. This would be based on how large their past transaction volume
has been. For that reason maybe another approach is an additional
negotiation message between the merchant and wallet. Merchant sends payment
details -> wallet responds with their instant information requesting if an
instant transaction will be accepted for this transaction. Merchant weighs
the risk based on historical data about this particular instant provider
and the amount of the requested transaction -> Merchant responds yes or no.
That approach avoids the scaling issue, but also allows for Lawrence's use
case of charging the user a fee only in the case where the instant
transaction is supported.
On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <drice at greenmangosystems.com>
wrote:
> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>
> What if the protocol allowed multiple instant signatures on a transaction?
> Would it encourage more instant providers? For example, a new instant
> provider could bootstrap their own trust by paying an already trusted
> instant provider to co-sign the same transaction. This would be useful in
> the case that a new company tries to release a new wallet once the trust
> ring is already established. Nobody will use that wallet because it does
> not have the trusted history to do instant transactions, but if they can
> pay a small amount per transaction to a third party to cosign, they can
> build trust in their own signature till they can eventually have enough
> trust on their own. This could be how an individual user could grow trust
> in their own instant signature as well.
>
>
> On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> I think many of us feel it'd be better if this kind of thing were not
>> needed at all, however, the best way to ensure it doesn't end up being used
>> is to write code, not to try and block alternative approaches. If Bitcoin
>> is robust the market should sort it out. If it's robust for some
>> transactions and not others, that makes for a fun project for a future
>> generation of hackers to sort out.
>>
>> OK, enough philosophy - let's try and keep this thread just for
>> discussion of the BIP itself from now on. If you'd like to continue
>> debating the Future of Bitcoin please change the subject line and break it
>> out into a new thread.
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/f6c6111b/attachment.html>;
📝 Original message:Mike Hearn <mike at plan99.net> wrote:
>> 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?
Lawrence Nahum <lawrence at greenaddress.it> wrote:
> I think you are wrong here.
> Just because up to date credit cards charged the merchant which in turn
> charged you and the ordinary cash payer doesn't mean a newer and better
> system can't be transparent from day one.
I don't think a whitelist of trust is a practical approach because you are
going to want to have varying levels of trust in different instant
providers. This would be based on how large their past transaction volume
has been. For that reason maybe another approach is an additional
negotiation message between the merchant and wallet. Merchant sends payment
details -> wallet responds with their instant information requesting if an
instant transaction will be accepted for this transaction. Merchant weighs
the risk based on historical data about this particular instant provider
and the amount of the requested transaction -> Merchant responds yes or no.
That approach avoids the scaling issue, but also allows for Lawrence's use
case of charging the user a fee only in the case where the instant
transaction is supported.
On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <drice at greenmangosystems.com>
wrote:
> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>
> What if the protocol allowed multiple instant signatures on a transaction?
> Would it encourage more instant providers? For example, a new instant
> provider could bootstrap their own trust by paying an already trusted
> instant provider to co-sign the same transaction. This would be useful in
> the case that a new company tries to release a new wallet once the trust
> ring is already established. Nobody will use that wallet because it does
> not have the trusted history to do instant transactions, but if they can
> pay a small amount per transaction to a third party to cosign, they can
> build trust in their own signature till they can eventually have enough
> trust on their own. This could be how an individual user could grow trust
> in their own instant signature as well.
>
>
> On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> I think many of us feel it'd be better if this kind of thing were not
>> needed at all, however, the best way to ensure it doesn't end up being used
>> is to write code, not to try and block alternative approaches. If Bitcoin
>> is robust the market should sort it out. If it's robust for some
>> transactions and not others, that makes for a fun project for a future
>> generation of hackers to sort out.
>>
>> OK, enough philosophy - let's try and keep this thread just for
>> discussion of the BIP itself from now on. If you'd like to continue
>> debating the Future of Bitcoin please change the subject line and break it
>> out into a new thread.
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/f6c6111b/attachment.html>;