From: Daniel Rice <drice@greenmangosystems•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Lawrence Nahum <lawrence@greenaddress•it>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Mon, 16 Jun 2014 08:09:01 -0700 [thread overview]
Message-ID: <CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]
If you're hoping the instant providers list won't need to scale then you're
essentially saying that we need a solution to the double spend problem.
That is a good point. Double spends are one of the biggest issues remaining
in the protocol. I've seen so many people talk about bad experiences trying
to spend Bitcoin at a restaurant and waiting an hour for confirmations.
This entire BIP extension is a band aid for double spends. If double spends
are not resolved, there will be a million instant providers in the long run
and if double spends are resolved then this BIP extension is completely
unnecessary. Is solving doublespends off the table?
What if we solved doublespends like this: If a node receives 2 transactions
that use the same input, they can put both of them into the new block as a
proof of double spend, but the bitcoins are not sent to the outputs of
either transactions. They are instead treated like a fee and given to the
block solver node. This gives miners the needed incentive and tools to end
doublespends instead of being forced to favor one transaction over the
other.
I will write up a BIP if this seems like a practical approach.
On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <mike@plan99•net> wrote:
> 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?
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4458 bytes --]
next prev parent reply other threads:[~2014-06-16 15:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 12:00 Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15 9:22 ` Lawrence Nahum
2014-06-15 12:46 ` Andreas Schildbach
2014-06-15 14:09 ` Lawrence Nahum
2014-06-18 12:09 ` Lawrence Nahum
2014-06-18 13:25 ` Mike Hearn
2014-06-18 15:59 ` Daniel Rice
2014-06-18 16:09 ` Mike Hearn
2014-06-19 17:36 ` Daniel Rice
2014-06-25 14:01 ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25 ` Mike Hearn
2014-06-16 15:09 ` Daniel Rice [this message]
2014-06-16 15:26 ` Lawrence Nahum
2014-06-16 16:00 ` Daniel Rice
2014-06-16 16:07 ` Mike Hearn
2014-06-16 15:41 ` Paul Goldstein
2014-06-16 15:48 ` Mike Hearn
2014-06-16 16:30 ` Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:46 ` Mike Hearn
2014-06-16 20:53 ` Daniel Rice
2014-06-16 20:55 ` Mike Hearn
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice
2014-06-16 20:32 ` Alex Kotenko
2014-06-16 17:44 ` Jorge Timón
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 1:39 ` Tom Harding
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 9:15 ` Mike Hearn
2014-06-18 20:47 ` Natanael
2014-06-18 2:01 ` Tom Harding
2014-06-16 15:28 ` Lawrence Nahum
2014-06-16 15:43 ` Mike Hearn
2014-06-16 17:05 ` Lawrence Nahum
2014-06-16 8:53 Daniel Rice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com' \
--to=drice@greenmangosystems$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=lawrence@greenaddress$(echo .)it \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox