I have been noticing for some time the problem which Mike H. identified as
how we are bleeding nodes ~ losing nodes over time.
This link was referenced in the coindesk article of May 9, 2014:
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pq
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
Hi Odinn,
I think trying to incentivise nodes with money is tricky: it makes
intuitive sense but right now the market is flooded with supply relative to
demand. Yes, we worry about the falling number of nodes, but that's for
reasons that aren't really economic: the more nodes we have, the bigger a
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
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
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
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
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
>
> 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, 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
>
> 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
> 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
>
> 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
How can there be any kind of lottery that doesn't involve proof of work or
proof of stake? Without some resource-limiting factor, there is no way to limit
the number of "lottery tickets" any given individual could acquire. The very
process of Bitcoin mining was invented specifically to overcome
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
>
> 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:
> 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 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:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/2014 04:25 PM, Matt Whitlock wrote:
> How can there be any kind of lottery that doesn't involve proof of
> work or proof of stake? Without some resource-limiting factor,
> there is no way to limit the number of "lottery tickets" any given
> in
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
On Monday, 16 June 2014, at 5:07 pm, Justus Ranvier wrote:
> On 06/16/2014 04:25 PM, Matt Whitlock wrote:
> > How can there be any kind of lottery that doesn't involve proof of
> > work or proof of stake? Without some resource-limiting factor,
> > there is no way to limit the number of "lottery tic
>
> This is a cool idea, but doesn't it generate some perverse incentives? If
> I'm running a full node and I want to pay CheapAir for some plane tickets,
> I'll want to pay in the greatest number of individual transactions possible
Peers can calculate rewards based on number of inputs or total k
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
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
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 Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote:
> >
> > This is a cool idea, but doesn't it generate some perverse incentives? If
> > I'm running a full node and I want to pay CheapAir for some plane tickets,
> > I'll want to pay in the greatest number of individual transactions possible
>
There can be multiple independent transport networks for Bitcoin.
There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch).
As long as multihomed hosts that act as bridges then information will propagate
across all of them.
--
Justus Ranvier
-
sent with R2Mail2
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
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
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
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
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
On Mon, Jun 16, 2014 at 01:37:52PM -0700, 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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/2014 07:00 PM, Justus Ranvier wrote:
> There can be multiple independent transport networks for Bitcoin.
>
> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
> patch).
>
> As long as multihomed hosts that act as bridges then in
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 "
38 matches
Mail list logo
