On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum
wrote:
> [snip]
>
> Allow me to recap BIP changes in discussion:
>
> - making some changes to allow merchants to offer discounts in case of
> instant ?
> - allowing multiple signatures ?
>
> Did I miss anything? Thoughts on the above from others?
>
> 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
Den 17 jun 2014 17:59 skrev "Isidor Zeuner" :
>
> quote:
> > Mike Hearn, why don't we just have all nodes report attempted double
spends
> > through the node network. No need to involve the miners at all really,
or
> > do your suggestion but also report the double spend attempt. By waiting
> > mayb
>
> 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
> 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 askin
>
> - 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
Andreas Schildbach schildbach.de> writes:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed. Can you
> briefly describe the whole flow of messages on an example, including the
> BIP70 messages?
Updated the BIP
Please, let's talk about other anti-double spend things on a separate
thread.
On Tue, Jun 17, 2014 at 5:58 PM, Isidor Zeuner wrote:
> What prevents the following steps from happening:
>
I linked to Satoshi's post on this earlier, he explains why it works there,
assuming people follow the origin
On 6/16/2014 8:48 AM, Mike Hearn wrote:
> In practice of course this is something payment processors like Bitpay
> and Coinbase will think about. Individual cafes etc who are just using
> mobile wallets won't be able to deal with this complexity: if we can't
> make native Bitcoin work well enoug
On 6/16/2014 8:09 AM, Daniel Rice wrote:
> 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
quote:
> Mike Hearn, why don't we just have all nodes report attempted double spends
> through the node network. No need to involve the miners at all really, or
> do your suggestion but also report the double spend attempt. By waiting
> maybe 10-60 seconds (instead of 10 minutes for first conf), me
quote:
> On 6/16/14, Mike Hearn wrote:
> > If they decide to change to something like highest-fee-always-wins, then
> > they (again) centralise things by forcing all instant transactions to pay
> > GreenAddress and its competitors money - much though I like your product
> > Lawrence, let's hope th
Mike Hearn 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 "
Yes that's true. Though it's off topic, check out
http://www.certificate-transparency.org/ it's a project to force CA's
to publish all certs they make publicly.
--
HPCC Systems Open Source Big Data Platform from Lexis
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
sto
On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice
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
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
ins
True, enough philosophy. Once this BIP will be finalized - we will it's
schedule implementation in XBTerminal. This is a solution to the problem we
have, probably best one we have to date, so we will use it.
2014-06-16 19:09 GMT+01:00 Mike Hearn :
> I think many of us feel it'd be better if this
On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice
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 inter
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 ins
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 a
On 6/16/14, Mike Hearn wrote:
> If they decide to change to something like highest-fee-always-wins, then
> they (again) centralise things by forcing all instant transactions to pay
> GreenAddress and its competitors money - much though I like your product
> Lawrence, let's hope they don't collecti
Hi Lawrence/All
I'm afraid with this BIP for TTP of instant transactions we will end up in
VISA world again. As I see it - it's not about if the TTPs will centralize,
it's only when. Simply because if economy of scales makes growth profitable
and coming into this market is at least a little expen
Mike Hearn plan99.net> writes:
> As long as miners stick to Satoshi's first seen rule, which is the
default, it's useful:
>
>
> https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
>
>
>
>
> (this is the famous "snack machine" thread from 2010)
>
> If they decide to change to somet
Mike Hearn plan99.net> writes:
> Sure. I buy this. Although the credit card market is a great example of
what we don't want: a stagnant duopoly of trusted third parties who
rampantly abuse their position. So I'd hope we see either (a) nobody really
caring about this BIP because Bitcoin gives g
>
> I only meant that double spends minutes apart are possible and that by then
> the sole use of a monitor is too late even if it will tell you.
>
As long as miners stick to Satoshi's first seen rule, which is the default,
it's useful:
https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
Mike Hearn plan99.net> writes:
> Actually Tom is running a page where he shows double spends detected by
his node or relayed by mine (there are only two nodes in this little
detection network currently), and it does show double spends that occur
seconds, minutes or even days apart.
I only mea
>
> I read the comments on the PR. I mean no disrespect but this patch can't
> prevent double spends minutes apart and a solution is as good as it's
> weakest link.
>
Actually Tom is running a page where he shows double spends detected by his
node or relayed by mine (there are only two nodes in th
Mike Hearn plan99.net> writes:
> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.
I read the comments on the
>
> Come to think of it, is the payment protocol really the place to put this
> instant provider signature
>
Yes it's the right place. The original attempt at this concept was in fact
called *green addresses* and the idea was you could identify a spend from a
trusted wallet by checking which keys
> 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 beco
>
> Mike Hearn, why don't we just have all nodes report attempted double
> spends through the node network.
>
Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt mine
Mike Hearn, why don't we just have all nodes report attempted double spends
through the node network. No need to involve the miners at all really, or
do your suggestion but also report the double spend attempt. By waiting
maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can
be
>
> I don't see more than a bunch of accepted payment methods anywhere I
> ever been in my life, I don't see merchants trusting more than a handful of
> third parties.
>
Sure. I buy this. Although the credit card market is a great example of
what we *don't* want: a stagnant duopoly of trusted thir
Mike Hearn plan99.net> writes:
[snip]
> 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
Daniel Rice 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
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
Oh yes the other thing we need to decide is how to extend BIP70.
Protocol buffers have an extend keyword. But I'm not sure it's what we
really want. IMHO a simpler solution is to have a single "living" version
of the protobuf (where? in a new git repo?) which has all the fields
defined by all the
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 w
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 litera
Andreas Schildbach schildbach.de> writes:
> Generally I like the simplicity of this BIP. Still, I have more questions:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed.
Transactions message sole purpose is
Yes I meant only the "supports_instant" is not needed.
"trusted_instant_providers" makes sense to me.
Generally I like the simplicity of this BIP. Still, I have more questions:
What is the use of the Transactions message? Note the Payment message
already contains a transactions field that could b
Andreas Schildbach 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 yo
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 i
44 matches
Mail list logo
