📅 Original date posted:2017-03-30
📝 Original message:Apparently we will not get an understanding and we will probably be told
soon that this is going off topic, so short answer
Eh --> No, maybe you would like to quote Mozilla or the W3C too, all of
those organizations are financed by the big companies and are promoting
their interests (specs, DRM, etc), then would you really trust them?
A full node does not have to validate all tx and blocks, I am not aware
of any P2P system organized with peers and intermediate nodes (with no
incentive) that did survive (diaspora for example), and the most famous
one (who btw is handling much more traffic than what you describe) is
doing well because there is an intrinsic incentive for the users, see my
comment here
https://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation,
surprising to see that nobody raised those issues during the consultation
Paradoxally crypto currencies allow now to reward/sustain other systems,
then probably they should concentrate first on how to reward/sustain
themselves, different ideas have surfaced to reward the full nodes but
still seem very far to materialize
Coming back again to the subject, does anyone have any idea of who are
behind the existing full nodes and how to rank them according to their
participation to the network? Up to now there has been quasi no
discussion about what are the plans for the full nodes which tends to
suggest that this is obvious
Le 30/03/2017 à 03:14, Jared Lee Richardson a écrit :
> > I have heard such theory before, it's a complete mistake to think
> that others would run full nodes to protect their business and then yours,
>
> It is a complete mistake to think that others would create a massive
> website to share huge volumes of information without any charges or
> even any advertising revenue.
>
> https://en.wikipedia.org/wiki/List_of_most_popular_websites
>
> Wikipedia, 5th largest website. Well, I guess there's some exceptions
> to the complete mistake, eh?
>
> Relying on other nodes to provide verification for certain types of
> transactions is completely acceptable. If I'm paying a friend $100,
> or paying my landlord $500, that's almost certainly totally fine.
> There's nothing that says SPV nodes can't source verifications from
> multiple places to prevent one source from being compromised. There's
> also some proposed ideas for fraud proofs that could be added, though
> I'm not familiar with how they work. If verification was a highly in
> demand service, but full nodes were expensive, companies would spring
> up that offered to verify transactions for a miniscule fee per month.
> They couldn't profit from 100 customers, but they could profit from
> 10,000 customers, and their reputation and business would rely on
> trustworthy verification services.
>
> I certainly wouldn't suggest any of those things for things like
> million dollar purchase, or a purchase where you don't know the seller
> and have no recourse if something goes wrong, or a purchase where
> failure to complete has life-altering consequences. Those
> transactions are the vast minority of transactions, but they need the
> additional security of full-node verification. Why is it unreasonable
> to ask them to pay for it, but not also ask other people who really
> don't need that security to pay for it? If a competing blockchain
> successfully offers both high security and low-fee users exactly what
> that particular user needs, they have a major advantage against one
> that only caters to one group or the other.
>
> > Running a full node is trivial and not expensive for people who know
> how to do it, even with much bigger blocks,
>
> This logic does not hold against the scale of the numbers. Worldwide
> 2015 transaction volume was 426 billion and is growing by almost 10%
> per year. In Bitcoin terms, that's 4.5 GB blocks, and approximately
> $30,000 in bandwidth a month just to run a pruning node. And there's
> almost no limit to the growth - 426 billion transactions is despite
> the fact that the majority of humans on earth are unbanked and did not
> add a single transaction to that number.
>
> I don't believe the argument that Bitcoin can serve all humans on
> earth is any more valid than the argument that any computer hardware
> should be able to run a node. Low node operational costs mean a
> proportional penalty to Bitcoin's usability, adoption, and price. Low
> transaction fee costs mean a proportional high node operational cost,
> and therefore possibly represent node vulnerabilities or verification
> insecurities.
>
> There's a balancing point in the middle somewhere that achieves the
> highest possible Bitcoin usability without putting the network at
> risk, and providing layers of security only for the transactions that
> truly need it and can justify the cost of such security.
>
>
>
> On Wed, Mar 29, 2017 at 3:33 PM, Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> I have heard such theory before, it's a complete mistake to think
> that others would run full nodes to protect their business and
> then yours, unless it is proven that they are decentralized and
> independent
>
> Running a full node is trivial and not expensive for people who
> know how to do it, even with much bigger blocks, assuming that the
> full nodes are still decentralized and that they don't have to
> fight against big nodes who would attract the traffic first
>
> I have posted many times here a small proposal, that exactly
> describes what is going on now, yes miners are nodes too... it's
> disturbing to see that despite of Tera bytes of BIPs, papers, etc
> the current situation is happening and that all the supposed
> decentralized system is biased by centralization
>
> Do we know what majority controls the 6000 full nodes?
>
>
> Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
>> > Perhaps you are fortunate to have a home computer that has more
>> than a single 512GB SSD. Lots of consumer hardware has that
>> little storage.
>>
>> That's very poor logic, sorry. Restricted-space SSD's are not a
>> cost-effective hardware option for running a node. Keeping
>> blocksizes small has significant other costs for everyone.
>> Comparing the cost of running a node under arbitrary conditons A,
>> B, or C when there are far more efficient options than any of
>> those is a very bad way to think about the costs of running a
>> node. You basically have to ignore the significant consequences
>> of keeping blocks small.
>>
>> If node operational costs rose to the point where an entire wide
>> swath of users that we do actually need for security purposes
>> could not justify running a node, that's something important for
>> consideration. For me, that translates to modern hardware that's
>> relatively well aligned with the needs of running a node -
>> perhaps budget hardware, but still modern - and above-average
>> bandwidth caps.
>>
>> You're free to disagree, but your example only makes sense to me
>> if blocksize caps didn't have serious consequences. Even if
>> those consequences are just the threat of a contentious fork by
>> people who are mislead about the real consequences, that threat
>> is still a consequence itself.
>>
>> On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Perhaps you are fortunate to have a home computer that has
>> more than a single 512GB SSD. Lots of consumer hardware has
>> that little storage. Throw on top of it standard consumer
>> usage, and you're often left with less than 200 GB of free
>> space. Bitcoin consumes more than half of that, which feels
>> very expensive, especially if it motivates you to buy another
>> drive.
>>
>> I have talked to several people who cite this as the primary
>> reason that they are reluctant to join the full node club.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
> --
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>;
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>;
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> <https://github.com/Ayms/torrent-live>;
> node-Tor : https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>;
> GitHub : https://www.github.com/Ayms
>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/cf114980/attachment-0001.html>;
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 17:58:28
in reply to nevent1q…9qnu
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 17:58:28Event JSON
{
"id": "b89acfb00b14590b8bb745bbf505ce1bf55b5c69ef5fdf173dd75e161ba76329",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686160708,
"kind": 1,
"tags": [
[
"e",
"f66fb8ea0b053d3b896ce377aea38775ffc7975376c3ee96291861cf920b456b",
"",
"root"
],
[
"e",
"2aa55b5d63577d0d503b78f1f8c66688ef9dcf5a8725622bf17d0e6e6e9ec326",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2017-03-30\n📝 Original message:Apparently we will not get an understanding and we will probably be told\nsoon that this is going off topic, so short answer\n\nEh --\u003e No, maybe you would like to quote Mozilla or the W3C too, all of\nthose organizations are financed by the big companies and are promoting\ntheir interests (specs, DRM, etc), then would you really trust them?\n\nA full node does not have to validate all tx and blocks, I am not aware\nof any P2P system organized with peers and intermediate nodes (with no\nincentive) that did survive (diaspora for example), and the most famous\none (who btw is handling much more traffic than what you describe) is\ndoing well because there is an intrinsic incentive for the users, see my\ncomment here\nhttps://ec.europa.eu/futurium/en/content/final-report-next-generation-internet-consultation,\nsurprising to see that nobody raised those issues during the consultation\n\nParadoxally crypto currencies allow now to reward/sustain other systems,\nthen probably they should concentrate first on how to reward/sustain\nthemselves, different ideas have surfaced to reward the full nodes but\nstill seem very far to materialize\n\nComing back again to the subject, does anyone have any idea of who are\nbehind the existing full nodes and how to rank them according to their\nparticipation to the network? Up to now there has been quasi no\ndiscussion about what are the plans for the full nodes which tends to\nsuggest that this is obvious\n\n\nLe 30/03/2017 à 03:14, Jared Lee Richardson a écrit :\n\u003e \u003e I have heard such theory before, it's a complete mistake to think\n\u003e that others would run full nodes to protect their business and then yours,\n\u003e\n\u003e It is a complete mistake to think that others would create a massive\n\u003e website to share huge volumes of information without any charges or\n\u003e even any advertising revenue.\n\u003e\n\u003e https://en.wikipedia.org/wiki/List_of_most_popular_websites\n\u003e\n\u003e Wikipedia, 5th largest website. Well, I guess there's some exceptions\n\u003e to the complete mistake, eh?\n\u003e\n\u003e Relying on other nodes to provide verification for certain types of\n\u003e transactions is completely acceptable. If I'm paying a friend $100,\n\u003e or paying my landlord $500, that's almost certainly totally fine. \n\u003e There's nothing that says SPV nodes can't source verifications from\n\u003e multiple places to prevent one source from being compromised. There's\n\u003e also some proposed ideas for fraud proofs that could be added, though\n\u003e I'm not familiar with how they work. If verification was a highly in\n\u003e demand service, but full nodes were expensive, companies would spring\n\u003e up that offered to verify transactions for a miniscule fee per month. \n\u003e They couldn't profit from 100 customers, but they could profit from\n\u003e 10,000 customers, and their reputation and business would rely on\n\u003e trustworthy verification services.\n\u003e\n\u003e I certainly wouldn't suggest any of those things for things like\n\u003e million dollar purchase, or a purchase where you don't know the seller\n\u003e and have no recourse if something goes wrong, or a purchase where\n\u003e failure to complete has life-altering consequences. Those\n\u003e transactions are the vast minority of transactions, but they need the\n\u003e additional security of full-node verification. Why is it unreasonable\n\u003e to ask them to pay for it, but not also ask other people who really\n\u003e don't need that security to pay for it? If a competing blockchain\n\u003e successfully offers both high security and low-fee users exactly what\n\u003e that particular user needs, they have a major advantage against one\n\u003e that only caters to one group or the other.\n\u003e\n\u003e \u003e Running a full node is trivial and not expensive for people who know\n\u003e how to do it, even with much bigger blocks,\n\u003e\n\u003e This logic does not hold against the scale of the numbers. Worldwide\n\u003e 2015 transaction volume was 426 billion and is growing by almost 10%\n\u003e per year. In Bitcoin terms, that's 4.5 GB blocks, and approximately\n\u003e $30,000 in bandwidth a month just to run a pruning node. And there's\n\u003e almost no limit to the growth - 426 billion transactions is despite\n\u003e the fact that the majority of humans on earth are unbanked and did not\n\u003e add a single transaction to that number.\n\u003e\n\u003e I don't believe the argument that Bitcoin can serve all humans on\n\u003e earth is any more valid than the argument that any computer hardware\n\u003e should be able to run a node. Low node operational costs mean a\n\u003e proportional penalty to Bitcoin's usability, adoption, and price. Low\n\u003e transaction fee costs mean a proportional high node operational cost,\n\u003e and therefore possibly represent node vulnerabilities or verification\n\u003e insecurities.\n\u003e\n\u003e There's a balancing point in the middle somewhere that achieves the\n\u003e highest possible Bitcoin usability without putting the network at\n\u003e risk, and providing layers of security only for the transactions that\n\u003e truly need it and can justify the cost of such security.\n\u003e\n\u003e\n\u003e\n\u003e On Wed, Mar 29, 2017 at 3:33 PM, Aymeric Vitte \u003cvitteaymeric at gmail.com\n\u003e \u003cmailto:vitteaymeric at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e I have heard such theory before, it's a complete mistake to think\n\u003e that others would run full nodes to protect their business and\n\u003e then yours, unless it is proven that they are decentralized and\n\u003e independent\n\u003e\n\u003e Running a full node is trivial and not expensive for people who\n\u003e know how to do it, even with much bigger blocks, assuming that the\n\u003e full nodes are still decentralized and that they don't have to\n\u003e fight against big nodes who would attract the traffic first\n\u003e\n\u003e I have posted many times here a small proposal, that exactly\n\u003e describes what is going on now, yes miners are nodes too... it's\n\u003e disturbing to see that despite of Tera bytes of BIPs, papers, etc\n\u003e the current situation is happening and that all the supposed\n\u003e decentralized system is biased by centralization\n\u003e\n\u003e Do we know what majority controls the 6000 full nodes?\n\u003e\n\u003e\n\u003e Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :\n\u003e\u003e \u003e Perhaps you are fortunate to have a home computer that has more\n\u003e\u003e than a single 512GB SSD. Lots of consumer hardware has that\n\u003e\u003e little storage.\n\u003e\u003e\n\u003e\u003e That's very poor logic, sorry. Restricted-space SSD's are not a\n\u003e\u003e cost-effective hardware option for running a node. Keeping\n\u003e\u003e blocksizes small has significant other costs for everyone. \n\u003e\u003e Comparing the cost of running a node under arbitrary conditons A,\n\u003e\u003e B, or C when there are far more efficient options than any of\n\u003e\u003e those is a very bad way to think about the costs of running a\n\u003e\u003e node. You basically have to ignore the significant consequences\n\u003e\u003e of keeping blocks small.\n\u003e\u003e\n\u003e\u003e If node operational costs rose to the point where an entire wide\n\u003e\u003e swath of users that we do actually need for security purposes\n\u003e\u003e could not justify running a node, that's something important for\n\u003e\u003e consideration. For me, that translates to modern hardware that's\n\u003e\u003e relatively well aligned with the needs of running a node -\n\u003e\u003e perhaps budget hardware, but still modern - and above-average\n\u003e\u003e bandwidth caps.\n\u003e\u003e\n\u003e\u003e You're free to disagree, but your example only makes sense to me\n\u003e\u003e if blocksize caps didn't have serious consequences. Even if\n\u003e\u003e those consequences are just the threat of a contentious fork by\n\u003e\u003e people who are mislead about the real consequences, that threat\n\u003e\u003e is still a consequence itself.\n\u003e\u003e\n\u003e\u003e On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e Perhaps you are fortunate to have a home computer that has\n\u003e\u003e more than a single 512GB SSD. Lots of consumer hardware has\n\u003e\u003e that little storage. Throw on top of it standard consumer\n\u003e\u003e usage, and you're often left with less than 200 GB of free\n\u003e\u003e space. Bitcoin consumes more than half of that, which feels\n\u003e\u003e very expensive, especially if it motivates you to buy another\n\u003e\u003e drive.\n\u003e\u003e\n\u003e\u003e I have talked to several people who cite this as the primary\n\u003e\u003e reason that they are reluctant to join the full node club.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\n\u003e -- \n\u003e Zcash wallets made simple: https://github.com/Ayms/zcash-wallets\n\u003e \u003chttps://github.com/Ayms/zcash-wallets\u003e\n\u003e Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\n\u003e \u003chttps://github.com/Ayms/bitcoin-wallets\u003e\n\u003e Get the torrent dynamic blocklist: http://peersm.com/getblocklist\n\u003e Check the 10 M passwords list: http://peersm.com/findmyass\n\u003e Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org\n\u003e Peersm : http://www.peersm.com\n\u003e torrent-live: https://github.com/Ayms/torrent-live\n\u003e \u003chttps://github.com/Ayms/torrent-live\u003e\n\u003e node-Tor : https://www.github.com/Ayms/node-Tor\n\u003e \u003chttps://www.github.com/Ayms/node-Tor\u003e\n\u003e GitHub : https://www.github.com/Ayms\n\u003e\n-- \nZcash wallets made simple: https://github.com/Ayms/zcash-wallets\nBitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\nGet the torrent dynamic blocklist: http://peersm.com/getblocklist\nCheck the 10 M passwords list: http://peersm.com/findmyass\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.org\nPeersm : http://www.peersm.com\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nGitHub : https://www.github.com/Ayms\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/cf114980/attachment-0001.html\u003e",
"sig": "b9ee3c7de1b440955b6dfa69c073142772d82e470f66e98d453c1bb6b89dec37cf80755a1d3f5a55a5db8f4254fda63b8b06a1b50505ceeda365c1a22d8e6bf3"
}