On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:

optional uint64 allowfee tag number=1000

Let's just use a normal/low tag number. The extensions mechanism is great for people who want to extend the protocol outside the core development process. It'd be weird if nobody ever used the low numbers again though.

Tag numbers are varint encoded so using smaller ones does have a minor efficiency benefit, it's not just aesthetics :)

Allow up to allowfee satoshis to be deducted from the amount paid to be used to pay Bitcoin network transaction fees. A wallet implementation must not reduce the amount paid for fees more than allowfee, and transaction fees must be equal to or greater than the amount reduced.

Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would have to attach at least that much in fees, right?

Also, why describe it as reducing the amount paid? Which output would be reduced in value? Why not just have it be added to the total value displayed to the user and the outputs are left alone/not reduced.

We also want to allow users to pay MORE in fees, if they need to (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.

I like the idea but it seems this gets us back to the original problem - senders don't care about confirmations, ever, not even if they make an annoying set of transactions. The protocol allows users to submit transactions directly to receivers, I guess, if the receiver does not like the transactions they get they could potentially reject the payment. But I'd hope that's really rare.

PS: I think there was also consensus that the BIP72 request=... should be shortened to just r=... (save 6 chars in QR codes). Unless somebody objects, I'll change the BIP and the reference implementation code to make it so...

Sweet, thanks!