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