Peter Grigor [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-12 📝 Original message:This was originally ...
📅 Original date posted:2014-05-12
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140512/34d187de/attachment.html>;
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140512/34d187de/attachment.html>;