rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-05-06 📝 Original message:On Wed, May 06, 2015 at 10:12:14PM +0000, Matt Corallo wrote: > Personally, I'm rather strongly against any commitment to a block size > increase in the near future. Long-term incentive compatibility requires > that there be some fee pressure, and that blocks be relatively > consistently full or very nearly full. What we see today are > transactions enjoying next-block confirmations with nearly zero pressure > to include any fee at all (though many do because it makes wallet code > simpler). Agreed. I'm not sure if you've seen this, but a good paper on this topic was published recently: "The Economics of Bitcoin Transaction Fees" Abstract -------- We study the economics of Bitcoin transaction fees in a simple static partial equilibrium model with the specificity that the system security is directly linked to the total computational power of miners. We show that any situation with a fixed fee is equivalent to another situation with a limited block size. In both cases, we give the optimal value of the transaction fee or of the block size. We also show that making the block size a non binding constraint and, in the same time, letting the fee be fixed as the outcome of a decentralized competitive market cannot guarantee the very existence of Bitcoin in the long-term. -http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize. > This allows the well-funded Bitcoin ecosystem to continue building > systems which rely on transactions moving quickly into blocks while > pretending these systems scale. Thus, instead of working on technologies I think this lack of understanding of the limitations of blockchain tech is very dangerous, never mind, downright misleading. I keep running into startups at conferences with completely unrealistic ideas about how large they'll be able to grow their on-blockchain businesses. For example, a few weeks ago at the Stanford blockchain conference I spoke to a company planning on using multisig escrow contracts to settle financial instruments, and expected to be doing about as many transactions/day on the blockchain for their business within a year or so as all other Bitcoin users currently do combined. These guys quite frankly had no understanding of the issues, and had apparently based their plans on the highly optimistic Bitcoin wiki page on scalability.(1) (I'd fix this now, but the wiki seems to not be allowing logins) We'd do a lot of startups a lot of good to give them accurate, and honest, advice about the scalability of the system. The wiki definitely isn't that. Neither is the bitcoin.org developer documentation(2), which doesn't mention scalability at all. > which bring Bitcoin's trustlessness to systems which scale beyond a > blockchain's necessarily slow and (compared to updating numbers in a > database) expensive settlement, the ecosystem as a whole continues to > focus on building centralized platforms and advocate for changes to > Bitcoin which allow them to maintain the status quo[1]. Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way? The only proposal that I've seen that attempts to do this is John Dillon's proof-of-stake blocksize vote(4), and that is far from getting consensus. 1) https://en.bitcoin.it/wiki/Scalability 2) https://bitcoin.org/en/developer-guide 3) http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea 4) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e -------------- 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/20150506/113bc44d/attachment.sig>