Daniel Rice [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-16 to 2014-06-19
💬 Posted a total of 9 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:22:51

- reply

📅 Original date posted:2014-06-16
📝 Original message:Jumping in on this conversation because I've been doing research in this
area. Using a list of trusted providers in the payment details will be very
limiting and not scalable. I understand the reason for wanting the
supports_instant field, but I think that's a bad idea because the list
could literally be a million providers. Secondly, some merchants already
support instant transactions without any trust signature, so they should
also be able to advertise that as well.
I also don't believe that trusted or not trusted is a valid on and off
switch. For example, I might trust an instant provider for a 1 btc
transaction, but not 1,000,000 btc. Trust is all about the risk involved.
We can definitely learn from the current financial system in this realm.
I 100% agree with the In Payment Message portion of the BIP extension.
Here's how I think this will practically shake out in an automated way:
Anyone can become an instant provider, but nobody will trust them at first.
As that particular instant provider processes more and more transactions
without any double spends, they essentially build up trust. Based on the
past history of a particular instant provider a risk factor could be
calculated for a given transaction. This would also factor in the size of
the transaction. It would be very similar to a credit file showing the past
history of that particular instant provider based on all the transactions
they signed.
Andreas Schildbach <andreas <at> schildbach.de> writes:
> Just a quick comment:
>
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, why
> do you need it at all? Protobuf is designed so it will simply ignore
> fields you don't know. So you can just send the instant_* fields in the
> Payment message without harm.
Agreed, supports_instant is redundant and can/should/will go.
trusted_instant_providers on the other hand I think is needed.
Sometimes the providers will charge fees for instant.
While the software can ignore the fields,
users may not want to pay for instant when the merchant may not accept it or
care (even if it would not break the protocol it would still be a waste of
fees)
Does it make sense?
Not all transactions from GreenAddress provide double spend protection, there
are additional checks on prevout that are normally not done when spending
normally, etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/6b3ca796/attachment.html>

2023-06-07 15:22:48

- reply

📅 Original date posted:2014-06-16
📝 Original message:The trust can be more automated in this case than it can with CAs. The
difference is that when a CA does something it shouldn't, like generates an
extra cert for a government to use in spoofing a site, nobody knows about
it, unless they mess up. Double spends on the network can be monitored and
stored for history. Merchants can and will share information on instant
provider trust with eachother, so they will essentially be able to build up
a credit history on a given instant provider without really knowing who
they are.
On Mon, Jun 16, 2014 at 1:46 PM, Mike Hearn <mike at plan99.net> wrote:
> On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <drice at greenmangosystems.com
> > wrote:
>
>> True, that would work, but still how are you going to bootstrap the
>> trust? TREZOR is well known, but in a future where there could be 100
>> different companies trying to release a similar product to TREZOR it seems
>> like one company could corner the market by being the only one that is an
>> accepted instant provider at most vendors
>>
>
> It's no different to the CA problem. People can only mentally handle a few
> trust anchors, so for SSL it goes:
>
> 1 User -> 2-3 browser makers -> 100's of CAs -> millions of websites
>
> The trust starts out narrowly funnelled and grows outwards as things get
> outsourced.
>
> For this it'd go
>
> 1 merchant -> 4-5 payment processing engines -> dozens of hardware
> manufacturers -> hundreds of thousands of devices
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/c00bb23f/attachment.html>

2023-06-07 15:22:48

- reply

📅 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>

2023-06-07 15:22:47

- reply

📅 Original date posted:2014-06-16
📝 Original message:True, that would work, but still how are you going to bootstrap the trust?
TREZOR is well known, but in a future where there could be 100 different
companies trying to release a similar product to TREZOR it seems like one
company could corner the market by being the only one that is an accepted
instant provider at most vendors. It seems to encourage monopoly unless
there is a standard way to bootstrap trust in your signature.
On Mon, Jun 16, 2014 at 1:32 PM, Mike Hearn <mike at plan99.net> wrote:
> On Mon, Jun 16, 2014 at 10: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.
>>
>
> A provider does not have to be an interactive third party. One reason I
> suggested using X.509 is so secure hardware devices like the TREZOR could
> also be instant providers. The hardware would be tamperproof and assert
> using a secret key embedded in it that the tx came from a genuine,
> unflashed TREZOR. The the server can know the device won't double spend.
>
> In this way you have decentralised anti-double spending. Of course, it's
> an old solution. MintChip sort of worked a bit like this.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/6b6146b3/attachment.html>

2023-06-07 15:22:47

- reply

📅 Original date posted:2014-06-16
📝 Original message: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/d9d757fa/attachment.html>

2023-06-07 15:22:44

- reply

📅 Original date posted:2014-06-16
📝 Original message:> Any reason you think people will spread trust instead of consolidating of
a
bunch of instant transaction providers when time is critical?
Maybe you're right, but if you are, that's a huge reason not to implement
this. We should encourage proliferation of instant providers otherwise we
start becoming VISA all over again. That's a future for Bitcoin I'm not
excited about: "Use one of these 4 companies, or you need to wait an
impractical amount of time before your transaction will go through."
Come to think of it, is the payment protocol really the place to put this
instant provider signature or should it be in the actual Bitcoin
transaction? If we don't believe there is a valid practical solution to
doublespends (some people have already emailed me critical feedback on my
proposal) then we absolutely need a trust network, but we would also want
it to be part of the public ledger for everyone to see.
On Mon, Jun 16, 2014 at 8:26 AM, Lawrence Nahum <lawrence at greenaddress.it>
wrote:
> Daniel Rice <drice <at> greenmangosystems.com> writes:
>
> > 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.
>
> I am not sure if double spends can be resolved, at the moment they are not
> and I highly doubt you will see millions instant providers just like I
> don't
> see millions Certificate Authorities and I don't see Million Credit Card
> networks.
>
> Any reason you think people will spread trust instead of consolidating of a
> bunch of instant transaction providers when time is critical?
>
>
>
>
> ------------------------------------------------------------------------------
> 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/84ba0a06/attachment.html>

2023-06-07 15:22:43

- reply

📅 Original date posted:2014-06-16
📝 Original message: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 at 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 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/8765e1bb/attachment.html>

2023-06-07 15:22:42

- reply

📅 Original date posted:2014-06-19
📝 Original message:> Supporting it in the protocol is easy. Building such a thing: that's
hard. Decentralised automated reputation systems are complex and subtle.
Bitcoin is valuable as a protocol because it is truly decentralized. The
complexity involved in building this system was expansive, but I think we
can all agree it was worth the trouble. With this particular topic of
instant transactions it seems we have to be very careful about pushing
Bitcoin in a centralized direction for the sake of a simple quick solution.
Building an automated system to solve the instant transaction problem will
be difficult, but also well worth the effort, and exactly like you're
saying Mike, I just want to make sure the door is left open protocol wise
for a robust solution in the future.
On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <mike at plan99.net> wrote:
> I think that's true if you assume that the instant provider list is based
>> on a by hand created list of accepted instant providers. That's how VISA
>> works now and that's why I was asking for an approach where the
>> trusted_instant_providers list is scalable because that seems very
>> dangerous.
>>
>
> Supporting it in the protocol is easy. Building such a thing: that's hard.
> Decentralised automated reputation systems are complex and subtle.
>
> I don't feel strongly about whether the field should be "optional" or
> "repeated", 100% of implementations in the forseeable future would just
> look at the first item and ignore the rest. But if later someone did crack
> this problem it would lead to a simple upgrade path. So perhaps you're
> right and the protobuf should allow multiple signatures. It means a new
> sub-message to wrap the pki_type, pki_data and signature fields into one,
> and then making that repeated.
>
> Up to Lawrence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/29c44805/attachment.html>

2023-06-07 15:22:41

- reply

📅 Original date posted:2014-06-18
📝 Original message:> I'm not sure this is actually important or useful; trusting someone not
to double spend is a pretty binary thing
I think that's true if you assume that the instant provider list is based
on a by hand created list of accepted instant providers. That's how VISA
works now and that's why I was asking for an approach where the
trusted_instant_providers list is scalable because that seems very
dangerous.
Since you can detect when a double spend happens, the entire instant
provider list could be automatically generated based on a 3rd party network
that shares information between vendors and also monitors double spends. In
that scenario, there is no hand written exclusive list of accepted instant
providers. There is just a database of past history on all instant
providers. That database can be used to give a confidence score for a
specific instant provider for a given transaction amount. In this scenario,
a new wallet company would be able to earn trust over time. If the list is
made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for
instant transactions", then new wallet providers have to go around bribing
Bitpay and the other large merchant transaction providers to get on their
instant provider list.
Allowing more than one instant signature on a transaction is supposed to
help avoid that scenario. For example, lets say I want to establish my own
instant signature. I use a wallet that already has an accepted instant
signature, but it also allows me to add my own instant signature. I do this
so that I can start establishing trust in my own instant signature while
relying on their instant signature.
On Wed, Jun 18, 2014 at 6:25 AM, Mike Hearn <mike at plan99.net> wrote:
> - allowing multiple signatures ?
>
>
> I'm not sure this is actually important or useful; trusting someone not to
> double spend is a pretty binary thing. I'm not sure saying "you need to get
> three independent parties to sign off on this" is worth the hassle,
> especially because the first signature is obvious (your risk analysis
> provider or hardware) but the second and third are ..... who? Special
> purpose services you have to sign up for? Seems like a hassle.
>
> But it's up to you.
>
>
> ------------------------------------------------------------------------------
> 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/20140618/80b85a82/attachment.html>