This is just plain nonsense - you don't require a fee higher than 0.0002 (a tenth of what you just stated - and even 0.0001 is generally just as good) for most transactions and I am still successfully doing transactions with no fees (provided they are not for tiny amounts, are not very large in number of bytes and are reasonably well aged).

I don't think so - the market can't force a git pull request to get merged (only the core devs can do that).

And even if it could - the market can't code C++ (they've already had years to improve the situation and have not managed much improvement from the initial release in this area).

Am hopeful these problems will be fixed but I think your idea that they could be done in days seems to fly in the face of the current reality.

Some other things to consider:

1) Minimum fees for BTC transactions are getting into the cents (making it very unsuitable for "micro-transactions") whilst LTC tx fees are comparatively "tiny" (and would be expected to stay that way for a long time).

2) Apparently ASIC hardware for mining LTC is being talked about (although how likely the appearance of such hardware appearing in the next year or so is probably anyone's guess).

3) Bitcoin cannot currently handle > 7 TPS (a pitifully small amount compared to any major payment system). I am not suggesting that Litecoin can do much better but at least it would help take some of the pressure of the Bitcoin block chain by taking on a lot of smaller value txs.

4) The CEO of btcchina is the brother of the creator of Litecoin (and we all know how much the Chinese are liking Bitcoin already).

The current Bitcoin implementation has a max. block size of 1 MB (and most blocks tend to be less than a quarter of that).

It has been calculated that the theoretical max. # of txs per second at the moment is around 7 - it a pitiful amount when you compare that to any major payment system.

So if the whole world tried to use Bitcoin for making transactions any time soon then the result would most likely be the end of Bitcoin.

These problems are well known and are being worked on - but I would not be expecting any huge improvement for at least a few years.

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

Satoshi made some choices pretty much arbitrarily with things like average confirmation time and many alt coins you see tend to have much faster confirmation times (although as pointed out in the post above they are thus arguably not as secure as Bitcoin is because of this).

It's arguable whether the Bitcoin settings are the most effective but it would not be so easy to change them (we are pretty much stuck with what Satoshi chose).

In regards to the block sizes it would actually be less efficient in terms of storage space required to make them a lot smaller.

No worries - I'll just leave it to you guys that are in the "club".

Thanks for the reply - and I have no problem to write the code but more importantly "do you think it is a good idea"?

(writing code to just be ignored by the core devs is not one of my interests)

And I would be interested to know why it wouldn't require a hard fork also (I understand quite a bit about Bitcoin but am sure nowhere near as much as you do).

Wallet to wallet is no difference so yes 0.0001 at least unless you are happy to wait for a long time (i.e. > 24 hours).

I have started a new topic here: https://bitcointalk.org/index.php?topic=343234.0 as I don't think my idea is going to be considered in this topic.

The idea is to add to the end of a tx an optional new op code OP_CHECKFEE plus an amount (in satoshis) for the fee the tx will pay.

This would allow an offline signing device to sign a tx with the signer knowing both the amount to be output (currently available from the raw tx) and the fee (currently not knowable without the relevant full UTXO information).

It would require a hard fork to properly implement (as the idea would be that if the amount in OP_CHECKFEE does not match the tx fee then the tx would be invalid) although it could initially be ignored (in terms of validation) until a certain date in the future.

The advantage is that you could create offline signing devices that need *zero* information from the blockchain (very useful if you want to use QR codes for 100% air-gapped offline txs).

I mentioned the idea of using an OP_CHECKFEE <amount> instead (as it would only be a single addition to the end of the tx so wouldn't blow out the size).

It would still require a hard-fork but at least doesn't get involved with any of the existing SIG stuff.

If the idea is crap then *please* I'd appreciate an explanation.

But surely that risk is going to limit the ability to game the idea then?

(i.e. shouldn't an "honest" miner end up doing better?)

In the case of 0 fee txs sure they could just add their own (am not trying to help out 0 fee txs) but why would you do that if you can include txs that are paying a small fee?

Currently people even paying the minimum fee are waiting hours for confirmation due to the backlog which is due to the fact that miners are not going anywhere near the 1 MB limit.

EDIT: I see the point about "gaming" this and at this stage I don't have a good idea about how to stop that (although maybe ignoring 0 fees txs could help).

I don't believe that this particular idea has been brought up before (if so please give me a link so I can look into previous replies).


No-one would be forcing the miners to do anything - if they all decide it is not worth mining >X KB blocks then they simply won't and nothing will have changed.

This is not about changing the upper limit of the block size (currently 1MB) it is about trying to get more txs into blocks when they are only being ignored because of the "race" to discover the next block.

I don't think it would require any major change (although it obviously would be a hard fork). Each block is already timestamped so the only change for deciding to prefer an alternate chain would be that the timestamp of the "better" block was within x seconds of the first one (assuming the normal timestamp range check is valid).

This concept could also help stop the >50% "death due to empty blocks" scenario (when a miner/pool has enough hash power to simply keep creating empty blocks and therefore prevent any tx from ever happening).

In another thread it was mentioned that the main reason that mining pools prefer to mine blocks <250 KB is that by doing so they incur less chance of "losing the race" to solve the next block (correct me if I am wrong - this was my interpretation).

But what if the rules were changed so that given 2 possible solutions for the "next block" (new block 123456A or 123456B) that are close enough in time one should not prefer the first one seen but the one with the largest size (or the first only if the sizes are the same or the second is smaller).

Would this help us to get bigger blocks mined and keep the fees to an absolute minimum?

Okay - so am guessing the small display should have enough room to display the fee amount then.

Still it would be a lot nicer if offline signing did not have to know all about the inputs (and would allow for 100% secure offline tx signing that could be done with a very cheap device via QR codes).

BTW rather than add the input amount to each input why not just add a single operator at the end of the whole TX that verifies the fee amount (in satoshis) so something like OP_CHECKFEE <amount> (with the tx being invalid if the amount doesn't match the UTXO input amounts - output amounts)?

The problem is not that it might sign an invalid transaction but that it signs a *valid* one which outputs say 1 BTC but includes a 99 BTC fee (assuming the UTXO was 100 BTC).

The offline device can show you that 1 BTC is going to be output but it cannot tell you anything about the change if it doesn't have the relevant information (which I believe that the Trezor doesn't have).

Or have I missed something obvious here?

Only the "coinbase" is unspendable - all other amounts sent to that address could be spent (although Satoshi has chosen not to spend those UTXO's nor any of the other coinbase in the blocks he mined).