From: Justus Ranvier <justusranvier@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
Date: Mon, 16 Jun 2014 17:07:24 +0000 [thread overview]
Message-ID: <539F244C.2090009@gmail.com> (raw)
In-Reply-To: <53959513.H7tOyQYvqT@crushinator>
[-- 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 --]
next prev parent reply other threads:[~2014-06-16 17:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 8:12 Odinn Cyberguerrilla
2014-06-16 11:35 ` Mike Hearn
2014-06-16 16:25 ` Matt Whitlock
2014-06-16 17:07 ` Justus Ranvier [this message]
2014-06-16 17:26 ` Matt Whitlock
2014-06-16 17:59 ` Mike Hearn
2014-06-16 18:10 ` Matt Whitlock
2014-06-16 19:00 ` Justus Ranvier
2014-06-16 20:55 ` Justus Ranvier
2014-06-17 17:47 ` Odinn Cyberguerrilla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539F244C.2090009@gmail.com \
--to=justusranvier@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox