{"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 2:40 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003ewrote:\n\n\u003e     optional uint64 allowfee    tag number=1000\n\u003e\n\nLet's just use a normal/low tag number. The extensions mechanism is great\nfor people who want to extend the protocol outside the core development\nprocess. It'd be weird if nobody ever used the low numbers again though.\n\nTag numbers are varint encoded so using smaller ones does have a minor\nefficiency benefit, it's not just aesthetics :)\n\n\n\u003e Allow up to allowfee satoshis to be deducted from the amount paid to be\n\u003e used to pay Bitcoin network transaction fees. A wallet implementation must\n\u003e not reduce the amount paid for fees more than allowfee, and transaction\n\u003e fees must be equal to or greater than the amount reduced.\n\u003e\n\nHmmm. Why \"allow\"? Should it not be called min_fee instead? Wallets would\nhave to attach at least that much in fees, right?\n\nAlso, why describe it as reducing the amount paid? Which output would be\nreduced in value? Why not just have it be added to the total value\ndisplayed to the user and the outputs are left alone/not reduced.\n\n\n\u003e We also want to allow users to pay MORE in fees, if they need to\n\u003e (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.\n\u003e\n\nI like the idea but it seems this gets us back to the original problem -\nsenders don't care about confirmations, ever, not even if they make an\nannoying set of transactions. The protocol allows users to submit\ntransactions directly to receivers, I guess, if the receiver does not like\nthe transactions they get they could potentially reject the payment. But\nI'd hope that's really rare.\n\n\n\u003e PS: I think there was also consensus that the BIP72  request=...   should\n\u003e be shortened to just r=... (save 6 chars in QR codes).  Unless somebody\n\u003e objects, I'll change the BIP and the reference implementation code to make\n\u003e it so...\n\u003e\n\nSweet, thanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/26e3aaec/attachment.html\u003e"}