Quote from: stbgefltc on August 18, 2013, 03:49:16 PM

Quote from: Fuserleer on August 18, 2013, 03:12:05 PM

Simple fact is, arguing about something never got anything done.

It amuses me that these in the "know" never actually have anything substantial to show....too much time spent procrastinating about what they can do, instead of backing it up IMO.

Basically everyone can say they have the biggest cock, but all bets are off until the cocks are on the table.

Well, he does have CoolPages. But I'm gonna stop there, I said I was out of this argument :p

UPDATE : Regarding the fee calculation, the following RPC calls would be nice to have :

preparetransaction(sendAddress, amount, maxFee, lockInputs)
Prepares a transaction by using the following parameters :
sendAddress : b58 encoded destination address
amount : amount of coins to send.
maxFee : maximum fees the sender is willing to pay, or -1 to specify no limit.
lockInputs : whether the inputs used to prepare the transaction should be locked. This feature is mostly for wallets with high volumes of outgoing transactions, to ensure coins stay available until the
Return value : a JSON object { hex: "signed tx raw data", fee: "0.1" }, where hex contains the signed raw data for the transaction , ready to be passed to sendrawtransaction. fee contains the fee amount that has been included in the transaction when this fee does not exceed the user specified limit. If the required fee exceeds the user specified limit when he passed a positive value to maxFee, an error object is returned with a message stating the required transaction fees exceed the user's limit.

canceltransaction(hex)
Cancels a prepared transaction by using the following parameters :
hex : raw data of a previously prepared transaction.
Return value : boolean indicating success or not.

This call would be required in case preparetransaction was called with lockInputs = true.

If the user is satisfied with the prepared transaction and the applied fees, he can then submit the hex data to sendrawtransaction to broadcast his transaction on the network and get the transaction's ID.

Maybe its better to ask what the issue around fees is ?

Is it the unpredictable nature ?

Or

The fee increase and number ?

Because perhaps a simpler way is a lower overall fee structure and either an inflation or stake structure.

I'm in agreement that any distributed currency will find fair value even with an inflation model , this is as simple as the day is long .

Security is another concern , but to tell you the truth I don't see it as a large one well not as large as some others do.

There can be such things as " rolling security" this is not dissimilar to an accepted amount of security balanced with use and other factors .