📅 Original date posted:2014-06-16
📝 Original message:-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x38450DB5.asc
Type: application/pgp-keys
Size: 12464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/7a64d188/attachment.bin>;
Justus Ranvier [ARCHIVE] /
npub1k2…9qd6m
2023-06-07 15:22:54
in reply to nevent1q…awaw
Author Public Key
npub1k2eekmevs6gg60df75qpjw4a2atmy89vx28c8zqq5jxy64tuzrws39qd6mPublished at
2023-06-07 15:22:54Event JSON
{
"id": "f46d72c1245a745ddae3ecb5709cb85b65e89cfb54f1fa9b8e35fe4d1790d204",
"pubkey": "b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd",
"created_at": 1686151374,
"kind": 1,
"tags": [
[
"e",
"095df1fe4b7ef528c02bd48922260a81badde098fc527e09daf61f5e5ef71914",
"",
"root"
],
[
"e",
"af56ccf36fca300f5ca5e837d9eb35555566803031c3a75a1b4cd595eb107307",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-06-16\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn 06/16/2014 04:25 PM, Matt Whitlock wrote:\n\u003e How can there be any kind of lottery that doesn't involve proof of\n\u003e work or proof of stake? Without some resource-limiting factor,\n\u003e there is no way to limit the number of \"lottery tickets\" any given\n\u003e individual could acquire. The very process of Bitcoin mining was\n\u003e invented specifically to overcome the Sybil problem, which had\n\u003e plagued computer scientists for decades, and now you're proposing a\n\u003e system that suffers from the same problem. Or am I wrong about\n\u003e this?\n\nIf you allow the solution set to include pay-to-play networks, and not\njust free P2P networks, then it's easier to find a solution\n\nImagine every node is competing with its peers in terms of relevancy.\nRelevancy is established by delivering newly-seen transactions first.\n\nEach node keeps track of which of its peers send it transactions that\nit hadn't seen and forwarded to them yet (making sure that the\ntransactions do make it into a block) and uses that information to\ndetermine whether or not it should be paying that peer, or if that\npeer should be paying it, or if they are equal relevancy and no net\npayment is required.\n\nOnce any given pair of nodes can establish who, if anyone, should be\npaying they could use micropayment channels to handle payments.\n\nNodes that are well connected, and with high uptimes would end up\nbeing net recipients of payments. Mobile nodes and other low-uptime\nnodes would be net payers.\n\nNow that you've established a market for the service of delivering\ntransaction information, you can rely on price signals to properly\nmatch supply and demand.\n\nPeople who hate market-based solutions could always run these nodes\nand configure them to refuse to pay anyone, and to charge nothing to\ntheir peers, if that's what they wanted.\n\n\n- -- \nSupport online privacy by using email encryption whenever possible.\nLearn how here: http://www.youtube.com/watch?v=bakOKJFtB-k\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (GNU/Linux)\n\niQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO\n0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR\nrzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR\n7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4\n93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX\nQQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI=\n=9qQJ\n-----END PGP SIGNATURE-----\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0x38450DB5.asc\nType: application/pgp-keys\nSize: 12464 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/7a64d188/attachment.bin\u003e",
"sig": "4ac996a1612ffe4047d020140fb800497416e45347a6fc4ee99296c5bcb91a5ca93cf78f775835bdeac0c14a8b8ffb5fb2e3c8548b07f15ee6e9bf246fdee76b"
}