{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-02\n📝 Original message:On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote:\n\u003e \u003e the network. This would result in a significantly longer block interval,\n\u003e \u003e which also means a higher per-block transaction volume, which could\n\u003e \u003e cause the block size limit to legitimately be hit much sooner than\n\u003e \u003e expected.\n\u003e \n\u003e If this happens at all (the exchange rate of the coin can accomodate such\n\u003e expectation),\n\nThe exchange rate is not significantly influenced by these things. \nHistorically, it seems fairly obvious that the difficulty has followed value, \nnot value following difficulty.\n\n\u003e the local fee market will develop, fees will raise and complement mined\n\u003e coins, thus bringing more miners back to the game (together with expected\n\u003e higher exchange rate).\n\nDepends on the hashrate drop, and tolerance for higher fees, both of which are \nlargely unknown at this time. At least having code prepared for the negative \nscenarios in case of an emergency seems reasonable, even if we don't end up \nneeding to deploy it.\n\nLuke"}