{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-07-11\n📝 Original message:On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote:\n\u003e On Tue, Jul 12, 2022 at 12:26 AM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e Anyway, designing protocols for \"price go up forever\" hopium is a bad idea.\n\u003e \u003e\n\u003e \n\u003e I'm quite disappointed that this is what you've reduced my argument to. The\n\u003e price doesn't need hopium; if it stays between where it is now and the all\n\u003e time high, that is enough to make mining rewards appealing.\n\u003e \n\u003e Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo.\n\u003e The Pacific is big, but not *that* big.\n\u003e \n\u003e Certainly we should be designing protocols in anticipation of increased\n\u003e adoption, and not assuming the world will always be exactly as it is today?\n\nWe should design protocols that do reasonably well in *both* scenarios. Because\nthe future is unknown. Hell, I won't be surprised if further developments come\nalong that reduce demand for on-chain txs even further.\n\nThe fact is basing security budget in part on the total value of the coin being\nsecured very cleanly solves the problem of ensuring that there is sufficient\nmining reward. Similarly, we also have to plan for the potential environment\nwhere fee demand is very high. And we've done a good job of that, including\nLightning, replace-by-fee, etc.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/4918b612/attachment-0001.sig\u003e"}