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

[Justus Ranvier <justusranvier@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

-----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
> individual could acquire. The very process of Bitcoin mining was
> invented specifically to overcome the Sybil problem, which had
> plagued computer scientists for decades, and now you're proposing a
> system that suffers from the same problem. Or am I wrong about
> this?

If you allow the solution set to include pay-to-play networks, and not
just free P2P networks, then it's easier to find a solution

Imagine every node is competing with its peers in terms of relevancy.
Relevancy is established by delivering newly-seen transactions first.

Each node keeps track of which of its peers send it transactions that
it hadn't seen and forwarded to them yet (making sure that the
transactions do make it into a block) and uses that information to
determine whether or not it should be paying that peer, or if that
peer should be paying it, or if they are equal relevancy and no net
payment is required.

Once any given pair of nodes can establish who, if anyone, should be
paying they could use micropayment channels to handle payments.

Nodes that are well connected, and with high uptimes would end up
being net recipients of payments. Mobile nodes and other low-uptime
nodes would be net payers.

Now that you've established a market for the service of delivering
transaction information, you can rely on price signals to properly
match supply and demand.

People who hate market-based solutions could always run these nodes
and configure them to refuse to pay anyone, and to charge nothing to
their peers, if that's what they wanted.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO
0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR
rzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR
7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4
93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX
QQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI=
=9qQJ
-----END PGP SIGNATURE-----

[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 12659 bytes --]