{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-07\n📝 Original message:On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:\n\u003e OK, so lets do that. I've seen a lot of \"I'm not entirely comfortable\n\u003e with committing to this right now, but think we should eventually\", but\n\u003e not much \"I'd be comfortable with committing to this when I see X\". In\n\u003e the interest of ignoring debate and pushing people towards a consensus\n\u003e at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the\n\u003e second.\n\u003e \n\u003e Personally, there are several things that worry me significantly about\n\u003e committing to a blocksize increase, which I'd like to see resolved\n\u003e before I'd consider supporting a blocksize increase commitment.\n\u003e \n\u003e  * Though there are many proposals floating around which could\n\u003e significantly decrease block propagation latency, none of them are\n\u003e implemented today. I'd expect to see these not only implemented but\n\u003e being used in production (though I dont particularly care about them\n\u003e being all that stable). I'd want to see measurements of how they perform\n\u003e both in production and in the face of high packet loss (eg across the\n\u003e GFW or in the case of small/moderate DoS). In addition, I'd expect to\n\u003e see analysis of how these systems perform in the worst-case, not just\n\u003e packet-loss-wise, but in the face of miners attempting to break the system.\n\nIt's really important that we remember that we're building security\nsoftware: it *must* hold up well even in the face of attack. That means\nwe need to figure out how it can be attacked, what the cost/profits of\nsuch attacks are, and if the holes can be patched.  Just testing the\nsoftware with simulated loads is insufficient.\n\nAlso, re: breaking, don't forget that this may not be a malicious act.\nFor instance, someone can send contradictory transactions to different\nparts of the network simultaneously to prevent mempool consistency -\nthere's no easy way to fix this. There are also cases where miners have\ndifferent policy than others, e.g. version disagreements, commercial\ncontracts for tx mining, etc.\n\nFinally, remember that it's not in miners' incentives in many situations\nfor their blocks to propagate to more than ~30% of the hashing power.(1)\n\nPersonally, I'm really skeptical that we'll ever find a block\npropagation latency reduction technique that sucesfully meets all the\nabove criteria without changing the consensus algorithm itself.\n\n\n* How do we ensure miners don't cheat and stop validating blocks fully\nbefore building on them? This is a significant moral hazard with larger\nblocks if fees don't become significant, and can lead to dangerous\nforks. Also, think of the incentives: Why would a miner ever switch from\nthe longest chain, even if they don't actually have the blocks to back\nit up?\n\n* We need a clear understanding of how we expect new full nodes, pruned\nor not, to sync up to the blockchain. Obviously 20MB blocks\nsignificantly increases the time and data required to sync. Are we\nplanning on simply giving up on full validation and trusting others for\ncopies of UTXO sets? Are we going to rely on UTXO commitments? What\nhappens if the UTXO set size itself increases greatly?\n\n\u003e  * I'd very much like to see someone working on better scaling\n\u003e technology, both in terms of development and in terms of getting\n\u003e traction in the marketplace. I know StrawPay is working on development,\n\u003e though its not obvious to me how far they are from their website, but I\n\u003e dont know of any commitments by large players (either SPV wallets,\n\u003e centralized wallet services, payment processors, or any others) to\n\u003e support such a system (to be fair, its probably too early for such\n\u003e players to commit to anything, since anything doesnt exist in public).\n\nA good start would be for those players to commit to the general\nprinciples of these systems; if they can't commit explain why.\n\nFor instance I'd be very interested in knowing if services like Coinbase\nsee legal issues with adopting technologies such as payment channels\nbetween hosted wallet providers, payment processors, etc. I certainly\nwouldn't be surprised if they see doing anythign not on-blockchain as a\nsource of legal uncertainty - based on discussions I've had with\nregulatory types in this space it sounds like there's a reasonable\nchance protocol details such as requiring that transactions happen on a\npublic blockchain will be \"baked into\" regulatory requirements.\n\n\u003e  * I'd like to see some better conclusions to the discussion around\n\u003e long-term incentives within the system. If we're just building Bitcoin\n\u003e to work in five years, great, but if we want it all to keep working as\n\u003e subsidy drops significantly, I'd like a better answer than \"we'll deal\n\u003e with it when we get there\" or \"it will happen, all the predictions based\n\u003e on people's behavior today say so\" (which are hopefully invalid thanks\n\u003e to the previous point). Ideally, I'd love to see some real free pressure\n\u003e already on the network starting to develop when we commit to hardforking\n\u003e in a year.\n\nAgreed.\n\n\u003e Not just full blocks with some fees because wallets are\n\u003e including far greater fees than they really need to, but software which\n\u003e properly handles fees across the ecosystem, smart fee increases when\n\u003e transactions arent confirming (eg replace-by-fee, which could be limited\n\u003e to increase-in-fees-only for those worried about double-spends).\n\nFWIW I've got some funding to implement first-seen-safe replace-by-fee.\n\n1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000fe0a96ac84aeb2e4e5c246e947cd8e759bd5fb158a16caf\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/f6c7c97c/attachment.sig\u003e"}