On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum lawre...@greenaddress.it
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
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
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 cryptocurrenc...@quidecco.de
wrote:
What prevents the following steps from happening:
I linked to Satoshi's post on this earlier, he explains why it works there,
Andreas Schildbach andreas at 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
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.
Den 17 jun 2014 17:59 skrev Isidor Zeuner cryptocurrenc...@quidecco.de:
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.
quote:
On 6/16/14, Mike Hearn m...@plan99.net 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
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),
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
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 enough
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
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
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
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
Mike Hearn mike at 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
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 third
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 miners
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
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
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 this
Mike Hearn mike at 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
Mike Hearn mike at 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 something
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
On 6/16/14, Mike Hearn m...@plan99.net 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
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
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
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
On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice dr...@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
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
Mike Hearn m...@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
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
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 be
Andreas Schildbach andreas at 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
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
34 matches
Mail list logo
