[Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Odinn Cyberguerrilla
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:

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Lawrence Nahum
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Lawrence Nahum
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Lawrence Nahum
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Lawrence Nahum
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
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 tickets

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Mike Hearn
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 kb

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Alex Kotenko
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Jorge Timón
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
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 Peers

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Mike Hearn
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

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-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

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Daniel Rice
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