<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <span dir="ltr"><<a href="mailto:gavinandresen@gmail.com" target="_blank">gavinandresen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><span style="color:rgb(34,34,34)"> optional uint64 allowfee tag number=1000</span><br>
</div></div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Tag numbers are varint encoded so using smaller ones does have a minor efficiency benefit, it's not just aesthetics :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br>
</div></div></div></div></blockquote><div><br></div><div>Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would have to attach at least that much in fees, right?</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div>
<div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div>
<div>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...<br>
</div></div></div></div></blockquote><div><br></div><div>Sweet, thanks!</div></div></div></div>