From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wk1Pj-00017o-SN for bitcoin-development@lists.sourceforge.net; Tue, 13 May 2014 01:21:51 +0000 X-ACL-Warn: Received: from mail-ve0-f175.google.com ([209.85.128.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wk1Pi-0003xq-Fv for bitcoin-development@lists.sourceforge.net; Tue, 13 May 2014 01:21:51 +0000 Received: by mail-ve0-f175.google.com with SMTP id jw12so9819796veb.34 for ; Mon, 12 May 2014 18:21:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=LqVb6V8/pndGiO987E00AO2xdS2v9o1KVyNmSd8au+Q=; b=kXt8gs8yhirKgb/ZdcTnxbZQqBWKMPUBXSE/9ZUIUMzdc+tLoqFXI/12KovUnPSY77 G53cQHUR8Z9I3oVEkgqCtH8mhK9ZMomzONIJUmVK9FHAGgYg4XZhGJUqOicEbe80nw3X i11QVFB0RhG32dN4Lp7HJ9QH/dR6jeMLfW3N5sVAkQh3oYXs96JrrWgX5OQFhSQ401BG TCE9dEVOUp2VqVaZOzm+nqUvFYR6Pyyz4min0NwAQwA3syArGB3yc4eVnGgLkrxmJJrm 9l4xdh1j/sUXjQMC9z+tdMVH4YHEgm3XRVlJPUqyWCPiUWQhAkigrvZqemC09Dpw1v4F K4yw== X-Gm-Message-State: ALoCoQnfCgPA/KAyXZQ9i1L5J+1XlVzzjrEiqxynYiYojX5pKzQRM1VqDV3k7iC42sVybx6vVvKO MIME-Version: 1.0 X-Received: by 10.58.195.231 with SMTP id ih7mr4143662vec.32.1399944104714; Mon, 12 May 2014 18:21:44 -0700 (PDT) Received: by 10.220.3.66 with HTTP; Mon, 12 May 2014 18:21:44 -0700 (PDT) X-Originating-IP: [68.5.210.114] Date: Mon, 12 May 2014 18:21:44 -0700 Message-ID: From: Peter Grigor To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=047d7b67663011385e04f93de30c X-Spam-Score: 3.5 (+++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 2.5 US_DOLLARS_3 BODY: Mentions millions of $ ($NN, NNN, NNN.NN) 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1Wk1Pi-0003xq-Fv Subject: [Bitcoin-development] Bitcoin Fee Formula Proposal 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, 13 May 2014 01:21:52 -0000 --047d7b67663011385e04f93de30c Content-Type: text/plain; charset=UTF-8 This was originally submitted to the bitcoin github issue manager. I'm re-posting here. I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. By using a percentage of the input amount the transaction fee will always make sense no matter what the "price" of bitcoins may be in fiat; by dividing the fee by the number of confirmations we discourage hasty spends and reward savings (ie. old inputs); by multiplying the fee by the number of inputs we discourage "payment fragmenting." Let me further explain payment fragmenting by way of an example: Let's say I get paid $2,500 in bitcoins per month from my job. If I then take that $2,500 and pay for a coffee (right away, 1 confirmation) I'll be charged a fee of $2.50 because I'm charged according to the *input amount*, not the actual transaction size. Because of this it would behove my employer to pay me the $2,500 as one transaction with, perhaps, 100 output addresses at $25 apiece so that when I pay for my coffee I use one of the $25 unspent outputs. By multiplying the transaction fee be the number of inputs this provides a disincentive for payment fragmenting as multiple inputs will be required to pay for larger purchases. Furthermore this provides an incentive for wallet software to use the oldest input(s) which most closely match the transaction amount. For the example above: In real life a user's wallet would have a number of inputs to choose from and wouldn't use the newest "paycheck" input for the coffee purchase. Furthermore, even if the $2,500 input was the only input available, by waiting for 100 confirmations (less than a day) the transaction fee would be 2.5 cents. Transaction fees would then be calculated by the following formula: ((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS The INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by the creator of the transaction and should be optimized for the transaction amount -- the BASE_PERCENT would be hard-coded in the bitcoind software. The special case of zero CONFIRMATIONS will be treated as 1 confirmation in order to avoid a divide by zero error. For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost: - $1 to send $1,000,000 that has 100 confirmations; - $0.10 (10 cents) to send $1,000,000 that has 1,000 confirmations (approx. 1 week); - $0.10 (10 cents) to send $100 which has 1 confirmation; - $0.01 (1 cent) to send $100 which has 10 confirmations; - $0.001 (1/10 cent) to send $100 which has 100 confirmations (less than a day); I've put together a spreadsheet which shows the various fees by amount and confirmations -- the spreadsheet assumes one input for a transaction: https://docs.google.com/spreadsheets/d/1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=sharing --047d7b67663011385e04f93de30c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This was originally submitted to the bitcoin github issue manager. I'= m re-posting here.

I propose the transaction fee should be calculated from a percentage of the= input amount divided by the confirmations of the input multiplied by the n= umber of inputs.

By using a percentage of the input amount the transaction fee will always m= ake sense no matter what the "price" of bitcoins may be in fiat; = by dividing the fee by the number of confirmations we discourage hasty spen= ds and reward savings (ie. old inputs); by multiplying the fee by the numbe= r of inputs we discourage "payment fragmenting."

Let me further explain payment fragmenting by way of an example: Let's= say I get paid $2,500 in bitcoins per month from my job. If I then take th= at $2,500 and pay for a coffee (right away, 1 confirmation) I'll be cha= rged a fee of $2.50 because I'm charged according to the=C2=A0input= amount, not the actual transaction size. Because of this it would beh= ove my employer to pay me the $2,500 as one transaction with, perhaps, 100 = output addresses at $25 apiece so that when I pay for my coffee I use one o= f the $25 unspent outputs. By multiplying the transaction fee be the number= of inputs this provides a disincentive for payment fragmenting as multiple= inputs will be required to pay for larger purchases.

Furthermore this provides an incentive for wallet software to use the olde= st input(s) which most closely match the transaction amount. For the exampl= e above: In real life a user's wallet would have a number of inputs to = choose from and wouldn't use the newest "paycheck" input for = the coffee purchase. Furthermore, even if the $2,500 input was the only inp= ut available, by waiting for 100 confirmations (less than a day) the transa= ction fee would be 2.5 cents.

Transaction fees would then be calculated by the following formula:

((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS

The = INPUT_AMOUNT, CONFIRMATIONS and NUMBER_OF_INPUTS would be determined by the= creator of the transaction and should be optimized for the transaction amo= unt -- the BASE_PERCENT would be hard-coded in the bitcoind software. The s= pecial case of zero CONFIRMATIONS will be treated as 1 confirmation in orde= r to avoid a divide by zero error.

For example: if I choose a BASE_PERCENT of 0.1% and one input it will cost= :

  • $1 to send $1,000= ,000 that has 100 confirmations;
  • $0.10 (10 cents) to send $1,000,000 that has= 1,000 confirmations (approx. 1 week);
  • $= 0.10 (10 cents) to send $100 which has 1 confirmation;
  • $0.01 (1 cent) to send $100 which has 10 confirmations;
  • $0.001 (1/10 cent) to send $100 which has 100 confirmations= (less than a day);

I've put together a spreadsheet which shows the various fees by amount = and confirmations -- the spreadsheet assumes one input for a transaction:

https://docs.google.com/spreadsheets/d/= 1ovAQfxksQmOq3zYf79qFEDPCrSx58SmyK3Uwpu8iTUs/edit?usp=3Dsharing

--047d7b67663011385e04f93de30c--