{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-12-03\n📝 Original message:On Tue, Dec 3, 2013 at 11:36 AM, Drak \u003cdrak at zikula.org\u003e wrote:\n\n\u003e I dont like the idea of putting the min fee in the hands of the receiver.\n\u003e Seems like that will work against the best interests of senders in the long\n\u003e run.\n\u003e\n\nSenders have no interest in ever attaching any kind of fee, which is one\nreason we explored child-pays-for-parent for a while. It's not the sender\nwho cares about double spending risk. Left to their own devices, all\nsenders would always attach no fee at all (or rather: whatever the min was\nto get the transaction relayed to the merchant).\n\nHowever, receivers do want a fee attached, and ideally we would do this\nwithout redundant transactions. Hence, receivers asking senders to attach a\nfee and effectively folding it into the price that is paid. That is, if you\ngo into a restaurant and the menu says \"Burger: 10mBTC\" then when you come\nto pay, what you see on your phone screen is 10mBTC. The fact that actually\nthe shop with receiver 9.9mBTC and the tx fee is 0.1mBTC is hidden in the\nuser interface - creating a situation like many others, where receivers eat\na transaction cost. For instance in Europe sales taxes are included in the\nprice, not attached separately later.\n\nThere's no need to trust the vendor. If a vendor asks for a ridiculously\nhigh tx fee, it will just surface as uncompetitively priced goods/services.\nBuyers will go elsewhere.\n\n\n\u003e Why not try a different path of calculating the min fee like difficulty\n\u003e retarget. You can analyse the last 2016 blocks to find the average fee\n\u003e accepted per kb (which would include transactions that were included\n\u003e without fees) and then write that into the block as a soft recommendation\n\u003e that wallets could use in the UI. This way the price can vary up and down\n\u003e according to what people were willing to spend on fees and miners willing\n\u003e to accept.\n\u003e\n\nThat's what fee estimation does, essentially, minus the encoding into\nblocks. Once you start getting miners telling people what fees are directly\nyou run into cases where they might try to lie about their behaviour or\notherwise influence the average. Querying all nodes avoids that problem.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/ea2876a4/attachment.html\u003e"}