{"type":"rich","version":"1.0","author_name":"npub170s9de2ganthnna75443h70tnsn2lvmcq5365r0juk8nfa93lthqwjr45x","author_url":"https://nostr.ae/npub170s9de2ganthnna75443h70tnsn2lvmcq5365r0juk8nfa93lthqwjr45x","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-09\n📝 Original message:You people are the most selfish kind of people in the world. Blackmail\ndevelopers with overload of the system, to try to force them to urgently\ncome up with solutions to the problem. The solution is always going to\nbe... wait for it... \"increase the block size\". There is not enough time or\nmanpower to do anything else. We are witnessing a tragedy of the commons\nbefore our very eyes.\n\nOn 9 August 2015 at 00:05, Alex Morcos via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I agree\n\u003e There are a lot of difficult technical problems introduced by insufficient\n\u003e block space that are best addressed now.  As well as problems that scale\n\u003e will exacerbate like bootstrapping that we should develop solutions for\n\u003e first.\n\u003e\n\u003e\n\u003e Sent from my iPad\n\u003e\n\u003e On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e I see value in lowering the block size or leaving it where it is. We\n\u003e expect to run out of space, and I think it's a good idea to prepare for\n\u003e that, rather than avoid it.  When we run out of space and the block size is\n\u003e low, we will see problems.  If we raise the block size, we will NOT see\n\u003e these problems until bitcoin is bigger and more important and the pressure\n\u003e is higher.\n\u003e\n\u003e Someone mentioned that when the backlog grows faster than it shrinks, that\n\u003e is a real problem.  I don't think it is.  It is a problem for those who\n\u003e don't wait for even one confirmation, but backlogs in the past have already\n\u003e started training users to wait for at least one confirmation, or go\n\u003e off-chain.  I am comfortable leaving those zero-conf people in a little bit\n\u003e of trouble.  Everyone else can double-spend (perhaps that's not as easy as\n\u003e it should be in bitcoin core) and use a higher fee, thus competing for\n\u003e block space.  Yes, $5 transactions suck, but $0.15 is not so bad and about\n\u003e twice the average right now.\n\u003e\n\u003e Meanwhile, the higher fees everyone starts feeling like paying, along with\n\u003e the visibility of the problems caused by full-blocks, will provide\n\u003e excellent justification and motivation for increasing the limit.  My\n\u003e favorite thing to do is to have a solution ready for a problem I expect to\n\u003e see, see the problem (so I can measure things about it) and then implement\n\u003e the solution.\n\u003e\n\u003e In my experience, the single biggest reason not to run a full node has to\n\u003e do with starting from scratch: \"I used to run a full node, but last time I\n\u003e had to download the full blockchain, it took ___ days, so I just use (some\n\u003e wallet) now.\"  I think that has been improved with headers-first, but many\n\u003e people don't know it.\n\u003e\n\u003e I have some ideas how a \"full node\" could postpone being \"full\" but still\n\u003e be nearly completely operational so that the delay between startup and\n\u003e having a full blockchain is nearly painless.  It involves bonded\n\u003e representation of important not-so-large pieces of data (blocks that have\n\u003e my transactions, the complete UTXO as of some height, etc.).  If I know\n\u003e that I have some btc, I could offer it (say, 100 or 1000 transaction fees'\n\u003e worth) to anyone who will guarantee good data to me, and then when I have\n\u003e the whole blockchain, I will know if they were honest.  If done right, the\n\u003e whole network could know whether or not they were honest and enforce the\n\u003e bond if they weren't.  Credit the Lightening paper for parts of this idea.\n\u003e\n\u003e Dave\n\u003e\n\u003e On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Please try to focus on constructive technical comments.\n\u003e\u003e\n\u003e\u003e On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e What will the backlash be when people here that are pushing for\n\u003e\u003e \"off-chain-\n\u003e\u003e \u003e transactions\" fail to produce a properly working alternative, which\n\u003e\u003e \u003e essentially means we have to say NO to more users.\n\u003e\u003e\n\u003e\u003e But \u003e 99% of Bitcoin transactions are already off-chain.  There are\n\u003e\u003e multiple competing companies offering consumer \u0026 retail service with\n\u003e\u003e off-chain settlement.\n\u003e\u003e\n\u003e\u003e I wasnt clear but it seemed in your previous mail that you seemed to\n\u003e\u003e say you dont mind trusting other people with your money, and so\n\u003e\u003e presumably you are OK using these services, and so have no problem?\n\u003e\u003e\n\u003e\u003e \u003e At this time and this size of bitcoin community, my personal experience\n\u003e\u003e (and\n\u003e\u003e \u003e I've been part of many communities) saying NO to new customers\n\u003e\u003e\n\u003e\u003e Who said no to anything?  The systems of off-chain transfer already\n\u003e\u003e exist and are by comparison to Bitcoins protocol simple and rapid to\n\u003e\u003e adapt and scale.\n\u003e\u003e\n\u003e\u003e Indications are that we can even do off-chain at scale with Bitcoin\n\u003e\u003e similar trust-minimisation with lightning, and duplex payment\n\u003e\u003e channels; and people are working on that right now.\n\u003e\u003e\n\u003e\u003e I think it would be interesting and useful for someone, with an\n\u003e\u003e interest in low trust, high scale transactions, to work on and propose\n\u003e\u003e an interoperability standard and API for such off-chain services to be\n\u003e\u003e accessed by wallets, and perhaps periodic on-chain inter-service\n\u003e\u003e netting.\n\u003e\u003e\n\u003e\u003e Adam\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e I like to provide some work at no charge to prove my value. Do you need a\n\u003e techie?\n\u003e I own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003e \u003chttp://www.memeracing.net\u003e (in alpha).\n\u003e I'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e\n\u003e which now accepts Bitcoin.\n\u003e I also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e \"He ought to find it more profitable to play by the rules\" - Satoshi\n\u003e Nakamoto\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\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\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/e8166ff2/attachment.html\u003e"}