From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnmsR-0000dJ-5Z for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 10:06:47 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VnmsP-0001No-FE for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 10:06:47 +0000 Received: by mail-oa0-f43.google.com with SMTP id i7so14628617oag.2 for ; Tue, 03 Dec 2013 02:06:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.246.39 with SMTP id xt7mr59017187obc.16.1386065199987; Tue, 03 Dec 2013 02:06:39 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 02:06:39 -0800 (PST) In-Reply-To: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> Date: Tue, 3 Dec 2013 11:06:39 +0100 X-Google-Sender-Auth: NHyEpKdEhr27JZahwe6nZsDLuis Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11c2e224e183ce04ec9e7356 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VnmsP-0001No-FE Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Floating fees and SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:06:47 -0000 --001a11c2e224e183ce04ec9e7356 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen 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! --001a11c2e224e183ce04ec9e7356 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen@gmail.com<= /a>> wrote:
=
=C2=A0 =C2=A0 optional uint64 allowfee =C2=A0 =C2=A0tag number=3D1000=

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 do= es have a minor efficiency benefit, it's not just aesthetics :)
=C2=A0
Allow up to allowfee satoshis to be deducted from the amount paid to be us= ed to pay Bitcoin network transaction fees. A wallet implementation must no= t reduce the amount paid for fees more than allowfee, and transaction fees = must be equal to or greater than the amount reduced.


=C2=A0
We also want to allow users to pay MORE in fees, if they need to (frag= mented wallet, maybe, or big CoinJoin transaction) or decide to.
<= /div>

I like the idea but it se= ems this gets us back to the original problem - senders don't care abou= t confirmations, ever, not even if they make an annoying set of transaction= s. 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.
=C2=A0
PS: I think there was also consensus that the BIP72 =C2=A0request=3D..= . =C2=A0 should be shortened to just r=3D... (save 6 chars in QR codes). = =C2=A0Unless somebody objects, I'll change the BIP and the reference im= plementation code to make it so...

Sweet, thanks!
--001a11c2e224e183ce04ec9e7356--