Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnnpJ-0003yB-Pm for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:07:37 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.172 as permitted sender) client-ip=74.125.82.172; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f172.google.com; Received: from mail-we0-f172.google.com ([74.125.82.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VnnpI-0004e7-UB for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:07:37 +0000 Received: by mail-we0-f172.google.com with SMTP id w62so7727680wes.31 for ; Tue, 03 Dec 2013 03:07:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.13.142 with SMTP id h14mr1917661wic.3.1386068850565; Tue, 03 Dec 2013 03:07:30 -0800 (PST) Received: by 10.195.13.68 with HTTP; Tue, 3 Dec 2013 03:07:30 -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 21:07:30 +1000 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c23dc279061d04ec9f4dc5 X-Spam-Score: -0.6 (/) 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1VnnpI-0004e7-UB 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 11:07:37 -0000 --001a11c23dc279061d04ec9f4dc5 Content-Type: text/plain; charset=ISO-8859-1 Ok, revised spec: SPEC: message PaymentDeatils { ... optional uint64 minfee tag number=8 Pay at least minfee satoshis in transaction fees. Wallet software should add minfee to the amount the user authorizes and pays, and include at least minfee in the transaction created to pay miner's transaction fees. Wallet software may request that the user pays more, if it must create a complex transaction or judges that minfee is not sufficient for the transaction to be accepted by the network.. :ENDSPEC Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care how many kilobytes their transactions are, and they will just be confused if they're paying for a 10mBTC burger and are asked to pay 10.00011 or 9.9994 because the merchant has no idea how many kilobytes the paying transaction will be. -- -- Gavin Andresen --001a11c23dc279061d04ec9f4dc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, revised spec:

SPEC:

message PaymentDeatils {
=A0 =A0 ...
=A0 =A0 optional uint64 minfee =A0 =A0tag number=3D8

Pay at= least minfee satoshis in transaction fees. Wallet software should add minf= ee to the amount the user authorizes and pays, and include at least minfee = in the transaction created to pay miner's transaction fees. Wallet soft= ware may request that the user pays more, if it must create a complex trans= action or judges that minfee is not sufficient for the transaction to be ac= cepted by the network..

:ENDSPEC

Making it fee-per-kilobyte is a bad idea, in my opinion; = users don't care how many kilobytes their transactions are, and they wi= ll just be confused if they're paying for a 10mBTC burger and are asked= to pay 10.00011 or 9.9994 because the merchant has no idea how many kiloby= tes the paying transaction will be.

--
--
Gavin Andresen
--001a11c23dc279061d04ec9f4dc5--