rich1.0npub1j7cm657crpk3y4jkvm7hk0le3c8c4x8yuqflk5dvzuyxn8k845lsfvmlg6https://nostr.ae/npub1j7cm657crpk3y4jkvm7hk0le3c8c4x8yuqflk5dvzuyxn8k845lsfvmlg6njumphttps://nostr.ae📅 Original date posted:2016-03-02 📝 Original message:> BtcDrak tells me he has well-tested code for this in his altcoin Could you be more explicit, which altcoin is that? > I am unaware of any reason this would be controversial Probably not until you get to the details of any proposal. What is your exact proposal here? Algorithm? Parameters? As you likely know a too short time window would be dangerous for other reasons. Getting to an agreement as to what is reasonable or not is not necessarily trivial. Jeremie 2016-03-02 16:14 GMT+01:00 Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>: > On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote: >> > the network. This would result in a significantly longer block interval, >> > which also means a higher per-block transaction volume, which could >> > cause the block size limit to legitimately be hit much sooner than >> > expected. >> >> If this happens at all (the exchange rate of the coin can accomodate such >> expectation), > > The exchange rate is not significantly influenced by these things. > Historically, it seems fairly obvious that the difficulty has followed value, > not value following difficulty. > >> the local fee market will develop, fees will raise and complement mined >> coins, thus bringing more miners back to the game (together with expected >> higher exchange rate). > > Depends on the hashrate drop, and tolerance for higher fees, both of which are > largely unknown at this time. At least having code prepared for the negative > scenarios in case of an emergency seems reasonable, even if we don't end up > needing to deploy it. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev