[Bitcoin-development] Death by halving (pro-active proposals)
Instead of discussing what will happen when the subsidy is halved (which nobody really knows) maybe we can think about of what we can do to mitigate any damage in case something unwanted happens. Let's be proactive. For instance, any form of merged-mining (like higher frequency side-chains) will end-up increasing miners profit, even by a small margin. Then that margin can compensate miners not to turn off their equipment. Then we can encourage merge-mining on SHA-256, instead of discouraging SHA-256 alt-coins. Also we can encourage mining during the trouble period by creating a donation pool: suppose we manage to convince miners to donate 1% of their revenue in order to pay back to the miners for the first month after the reward halving. If every block pays 1% for 10 months, then every block during the first month of halving will earn 20% more. Of course, convincing miners of this may be difficult, but not impossible. It could be done automatically with nLockTime freeze of transactions with high fees, so no TTP is necessary. So here are two proposals, any other idea? Best regards, Sergio. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Death by halving (pro-active proposals)
Seconded - IMO a key future use of the chain will be securing other chains. I'm interested in pursuing the merged-mining angle. Getting chain hashes to a miner, and getting that miner payment from the chain, is key to this. Consider a future where there are 10,000 chains secured by one block... On Wed, Oct 29, 2014 at 10:34 AM, Sergio Lerner sergioler...@certimix.com wrote: Instead of discussing what will happen when the subsidy is halved (which nobody really knows) maybe we can think about of what we can do to mitigate any damage in case something unwanted happens. Let's be proactive. For instance, any form of merged-mining (like higher frequency side-chains) will end-up increasing miners profit, even by a small margin. Then that margin can compensate miners not to turn off their equipment. Then we can encourage merge-mining on SHA-256, instead of discouraging SHA-256 alt-coins. Also we can encourage mining during the trouble period by creating a donation pool: suppose we manage to convince miners to donate 1% of their revenue in order to pay back to the miners for the first month after the reward halving. If every block pays 1% for 10 months, then every block during the first month of halving will earn 20% more. Of course, convincing miners of this may be difficult, but not impossible. It could be done automatically with nLockTime freeze of transactions with high fees, so no TTP is necessary. So here are two proposals, any other idea? Best regards, Sergio. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)
On Mon, Oct 27, 2014 at 03:33:45PM -0400, Alex Morcos wrote: I've been playing around with the code for estimating fees and found a few issues with the existing code. I think this will address several observations that the estimates returned by the existing code appear to be too high. For instance see @cozz in Issue 4866 https://github.com/bitcoin/bitcoin/issues/4866. I don't have time to look at the details of your statistical methods unfortunately due to some deadlines, but a quick comment: You should think about the malleability of your estimates to attackers. For instance the current fee estimation code has a serious issue where it'll happily estimate ludicriously high fees based on very little date. There is a 'insane fees' failsafe, but it's IIRC set to allow transactions with fees of less than 100mBTC/tx, roughly $50 at current exchange rates. It's relatively easy to get a wallet into a condition where this happens as the estimations are considered valid even based on very little data - a simple sybil attack suffices. (e.g. the recently published paper(1) on Tor sybil attacks comes to mind as one example of many ways to do this) Obviously this could empty someone's wallet pretty quickly; an exchange that makes a few dozen transactions an hour could easily lose tens of thousands of dollars due to this exploit. Someone correct me if I'm wrong, but last I checked in git HEAD this exploit is still unfixed. A user-configurable failsafe limit is a pretty obvious solution here, albeit a crude one; it'd be interesting to see if a plausible security argument could be made for something more sophisticated, like taking into account coin-age of observed transactions that estimates are based on. 1) Bitcoin over Tor isn't a good idea, http://arxiv.org/abs/1410.6079 -- 'peter'[:-1]@petertodd.org 098d3c9095b47ff1fd692fef5ac6731340802c7c63d38bb0 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
