Topic: Idea: new rules for block validation - page 3. (Read 3885 times)

As I said, invalidate his blocks if he did not include old enough transactions. He will update if he wants to produce valid blocks. I am not suggesting we do this right now, of course, or we'll only have invalid blocks . A good scenario would be to activate the rules starting with a specific block number, chosen so at that moment the majority of the network is already updated.

How can you force a miner to include a tx in a block?  What if they don't update their software?

No, at the moment the 50 BTC/block prize is the motivation. Anyway, if some miners leave, the network will adapt. I do know that a lot of miners really believe in bitcoin and will continue mining even at a loss or with my rules in place.

I am not trying to alienate miners, but they have, IMHO, too much power regarding which transactions are included and when. Anyway, my rules are pretty reasonable for the miners too, I believe.

Also, I didn't say anything about the minimum fee. I have no problem increasing it or even making it a percentage of the transferred amount. I also don't have any problem in simply dropping no-fee transactions completely (maybe starting with block 210000) ?

What I do have a problem with is that at the moment it's impossible to predict when a transaction will be processed, even if you pay fees. This must be solved.

Fee - is the miner`s motivation for his work. If you enter a binding confirmation, then drop fee. Following will be leaving miners and the instability of the network. Some rules are necessary, but must keep track of all the consequences of the introduction of these rules.

Ideas which aren't attractive to miners will not be successful.

If your transaction doesn't get processed in the time frame you want, you should include a higher fee. That's the point of fees.

The only problem I see with the current implementation is that it doesn't seem like you can cancel your unprocessed transactions in order to try sending with a higher fee. But if that functionality is not possible in combination with all the benefits we have in the current implementation, so be it.

Hardware and bandwidth are cheap (and I will be running a dedicated full note for as long as Bitcoin exists). Light clients like Electrum are being developed, so I simply don't care about the blockchain size. Neither should the users, whose interests are the most important - transactions must be confirmed in a reasonable amount of time.

I wonder what you will do about the blockchain being 25920 megabytes larger 181 days from now?

After spending more than a day frustrated that one of my transactions didn't get through, even though it contained a fee, simply because it was too large, I came up with the following idea. I know some of it was already discusses here and there, but I thought I should write it again. I am starting from the assumption that the network as a whole is fast (I remember reading ~20 seconds propagation time for a new tx? can someone point me to that post/article?). I am also taking a position for the user's interest against the miner's interests (in other words, I don't care if the miners have to work more, or waste hashes, or make sure they are on a fast, well-connected node, if it helps the network).

How about we add these simple rules to validate new blocks:

* transactions which contain fees more than the minimum recommended have to be included in the next 3 blocks (~ 1/2 hour).
* transactions which contain fees have to be included in the next 72 blocks (~12 hours).
* all transactions must be included in the next 144 blocks (~24 hours).

When receiving a new block, the nodes will reject it as invalid, if there are transactions on the network which should have been included but are not. The end.

This also has the nice side effect that it will render some attacks impossible, for example a common scenario states that a miner with >50% hashing power can postpone transactions indefinitely.

I realize that there are some timing problems here, which are not trivial to solve, but I would be interested to hear what you think about the general idea?