{"type":"rich","version":"1.0","author_name":"npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","author_url":"https://nostr.ae/npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-03-29\n📝 Original message:Le 29/03/2017 à 11:16, Jared Lee Richardson via bitcoin-dev a écrit :\n\u003e Nodes process transactions and are paid nothing to do so, and their\n\u003e costs are 100x more relevant to the blocksize debate than a paper\n\u003e about miner costs.\n\u003e\n\u003e Miners are rewarded with fees; nodes are rewarded only by utility and\n\u003e price increases.\n\nNodes are rewarded by just nothing which is the main problem of the\nbitcoin network (who is therefore not a decentralized system today)\nalthough it seems like everybody is eluding the issue (as well as how to\nfind solutions to setup quickly full nodes as you quoted in another\nanswer to this thread, and of course design a decentralized system to\nmake sure that full nodes behave correctly)\n\nBitcoin would not be in this situation (ie maybe at the mercy of a very\nsmall minority of freeriders among all the entities involved in the\nnetwork, ie miners,  just seeking to make more and more money because\nthey invested in an anti-ecological pow, not understanding that bitcoin\nis not just about money) if more nodes were existing and could reject\ntheir blocks\n\nIt seems like the initial message of this thread(t) is an ultimatum:\nwhether you implement what we ask, whether we join BU and then \u003e 50 is\nalmost reached...\n\n\n\u003e\n\u003e On Tue, Mar 28, 2017 at 10:53 AM, Alphonse Pace via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e     Juan,\n\u003e\n\u003e     I suggest you take a look at this\n\u003e     paper: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf\n\u003e     \u003chttp://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf\u003e  It may help you\n\u003e     form opinions based in science rather than what appears to be\n\u003e     nothing more than a hunch.  It shows that even 4MB is unsafe. \n\u003e     SegWit provides up to this limit.\n\u003e\n\u003e     8MB is most definitely not safe today.\n\u003e\n\u003e     Whether it is unsafe or impossible is the topic, since Wang Chun\n\u003e     proposed making the block size limit 32MiB.  \n\u003e\n\u003e\n\u003e     Wang Chun,\n\u003e\n\u003e     Can you specify what meeting you are talking about?  You seem to\n\u003e     have not replied on that point.  Who were the participants and\n\u003e     what was the purpose of this meeting?\n\u003e\n\u003e     -Alphonse\n\u003e\n\u003e     On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia \u003cjg at 112bit.com\n\u003e     \u003cmailto:jg at 112bit.com\u003e\u003e wrote:\n\u003e\n\u003e         Alphonse,\n\u003e\n\u003e          \n\u003e\n\u003e         In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on\n\u003e         2016 and 32MB limit valid in next halving, from network,\n\u003e         storage and CPU perspective or 1MB was too high in 2010 what\n\u003e         is possible or 1MB is to low today.\n\u003e\n\u003e          \n\u003e\n\u003e         If is unsafe or impossible to raise the blocksize is a\n\u003e         different topic. \n\u003e\n\u003e          \n\u003e\n\u003e         Regards\n\u003e\n\u003e          \n\u003e\n\u003e         Juan\n\u003e\n\u003e          \n\u003e\n\u003e          \n\u003e\n\u003e         *From:*bitcoin-dev-bounces at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev-bounces at lists.linuxfoundation.org\u003e\n\u003e         [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev-bounces at lists.linuxfoundation.org\u003e] *On\n\u003e         Behalf Of *Alphonse Pace via bitcoin-dev\n\u003e         *Sent:* Tuesday, March 28, 2017 2:24 PM\n\u003e         *To:* Wang Chun \u003c1240902 at gmail.com\n\u003e         \u003cmailto:1240902 at gmail.com\u003e\u003e; Bitcoin Protocol Discussion\n\u003e         \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e\n\u003e         *Subject:* Re: [bitcoin-dev] Hard fork proposal from last\n\u003e         week's meeting\n\u003e\n\u003e          \n\u003e\n\u003e         What meeting are you referring to?  Who were the participants?\n\u003e\n\u003e          \n\u003e\n\u003e         Removing the limit but relying on the p2p protocol is not\n\u003e         really a true 32MiB limit, but a limit of whatever transport\n\u003e         methods provide.  This can lead to differing consensus if\n\u003e         alternative layers for relaying are used.  What you seem to be\n\u003e         asking for is an unbound block size (or at least determined by\n\u003e         whatever miners produce).  This has the possibility (and even\n\u003e         likelihood) of removing many participants from the network,\n\u003e         including many small miners.  \n\u003e\n\u003e          \n\u003e\n\u003e         32MB in less than 3 years also appears to be far beyond limits\n\u003e         of safety which are known to exist far sooner, and we cannot\n\u003e         expect hardware and networking layers to improve by those\n\u003e         amounts in that time.\n\u003e\n\u003e          \n\u003e\n\u003e         It also seems like it would be much better to wait until\n\u003e         SegWit activates in order to truly measure the effects on the\n\u003e         network from this increased capacity before committing to any\n\u003e         additional increases.\n\u003e\n\u003e          \n\u003e\n\u003e         -Alphonse\n\u003e\n\u003e          \n\u003e\n\u003e          \n\u003e\n\u003e          \n\u003e\n\u003e         On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev\n\u003e         \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e             I've proposed this hard fork approach last year in Hong\n\u003e             Kong Consensus\n\u003e             but immediately rejected by coredevs at that meeting,\n\u003e             after more than\n\u003e             one year it seems that lots of people haven't heard of it.\n\u003e             So I would\n\u003e             post this here again for comment.\n\u003e\n\u003e             The basic idea is, as many of us agree, hard fork is risky\n\u003e             and should\n\u003e             be well prepared. We need a long time to deploy it.\n\u003e\n\u003e             Despite spam tx on the network, the block capacity is\n\u003e             approaching its\n\u003e             limit, and we must think ahead. Shall we code a patch\n\u003e             right now, to\n\u003e             remove the block size limit of 1MB, but not activate it\n\u003e             until far in\n\u003e             the future. I would propose to remove the 1MB limit at the\n\u003e             next block\n\u003e             halving in spring 2020, only limit the block size to 32MiB\n\u003e             which is\n\u003e             the maximum size the current p2p protocol allows. This\n\u003e             patch must be\n\u003e             in the immediate next release of Bitcoin Core.\n\u003e\n\u003e             With this patch in core's next release, Bitcoin works just\n\u003e             as before,\n\u003e             no fork will ever occur, until spring 2020. But everyone\n\u003e             knows there\n\u003e             will be a fork scheduled. Third party services, libraries,\n\u003e             wallets and\n\u003e             exchanges will have enough time to prepare for it over the\n\u003e             next three\n\u003e             years.\n\u003e\n\u003e             We don't yet have an agreement on how to increase the\n\u003e             block size\n\u003e             limit. There have been many proposals over the past years,\n\u003e             like\n\u003e             BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248,\n\u003e             BU, and so\n\u003e             on. These hard fork proposals, with this patch already in\n\u003e             Core's\n\u003e             release, they all become soft fork. We'll have enough time\n\u003e             to discuss\n\u003e             all these proposals and decide which one to go. Take an\n\u003e             example, if we\n\u003e             choose to fork to only 2MB, since 32MiB already scheduled,\n\u003e             reduce it\n\u003e             from 32MiB to 2MB will be a soft fork.\n\u003e\n\u003e             Anyway, we must code something right now, before it\n\u003e             becomes too late.\n\u003e             _______________________________________________\n\u003e             bitcoin-dev mailing list\n\u003e             bitcoin-dev at lists.linuxfoundation.org\n\u003e             \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e             \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\n\u003e          \n\u003e\n\u003e\n\u003e\n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e     \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/a4a9932b/attachment-0001.html\u003e"}