Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On 06/19/2015 07:48 AM, Brooks Boyd wrote: > Has there been any talk about reducing the time between blocks? If > blocks were allowed to come twice as fast, they would be able to clear > pending transactions in the mempool the same as if the block size > doubled, but would allow mining to stay more decentralized since miners > wouldn't be working on such large-scale blocks? It would still take more > storage space to store the blockchain, though. https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07663.html -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On 05/13/2015 09:31 PM, Aaron Voisine wrote: > > by people and businesses deciding to not use on-chain settlement. > > I completely agree. Increasing fees will cause people voluntary > economize on blockspace by finding alternatives, i.e. not bitcoin. This strikes me as a leap. There are alternatives that still use bitcoin as the unit of value, such as sidechains, offchain, etc. To say that these are "not bitcoin" is misleading. > A fee however is a known, upfront cost... unpredictable transaction failure in > most cases will be a far higher, unacceptable cost to the user than the > actual fee. Are we sure that raising the block size is the only way to avoid "unpredictable transaction failure"? If so, and it's as bad as you say it is, aren't we screwed anyway when we inevitably start hitting the cap (even if it's raised 10x or 20x)? And if that's the case, then don't we do a disservice to users by continuing to pretend that we can make this problem go away? > The higher the costs of using the system, the lower the > adoption as a store-of-value. On what do you base this? Gold has a very high cost of using (storage, transport) and yet is perhaps the most widely accepted store of value. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On 05/08/2015 11:36 PM, Gregory Maxwell wrote: > Another related point which has been tendered before but seems to have > been ignored is that changing how the size limit is computed can help > better align incentives and thus reduce risk. E.g. a major cost to the > network is the UTXO impact of transactions, but since the limit is blind > to UTXO impact a miner would gain less income if substantially factoring > UTXO impact into its fee calculations; and without fee impact users have > little reason to optimize their UTXO behavior. Along the lines of aligning incentives with a diversity of costs to a variety of network participants, I am curious about reactions to Justus' general approach: http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ I realize it relies on pie-in-the-sky ideas like micropayment channels, but I wonder if it's a worthy long-term ideal direction for this stuff. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
