Topic: Idea: new rules for block validation - page 2. (Read 3870 times)

The current "suggested fee" feature of the client is a temporary hack. In the future it will receive as input the desired wait time (or use a default value) and give a reasonable estimate based on historical data.

The protocol supports multiple versions of a transaction. It should be possible to use this to release a new version of the transaction with a higher fee if the old one isn't accepted, and the client can do this automatically.

Maybe I didn't express myself correctly. I don't want miners to do something much different than what they do now. Obviously, I don't want a service *for me*. I just want to add a "and don't leave out tx older than x blocks" restriction - which, looking at http://bitcoinstats.org/, is not even a problem, since most transactions are confirmed much faster anyway. For the miners the effect will be minimal. For the end-user though, this restriction brings a much-needed warranty.

You might be right about the technical glitch. I supposed my tx simply tripped some checks in the miners. I assumed it was intentional, but I might be wrong.

I do believe the problem still remains, though - how can we make sure transactions are always confirmed in a predetermined time (max. number of blocks)?

The standard suggestion - "increase fee" - has the following problems:

* it's impossible for a user to determine what the fee should be. Most will use the suggested value, which might or might not be enough. And...

* ...once a transaction is out, there's nothing you can do to speed it up. I suggested that the network should guarantee that it will get into a block, what other solutions can there be?

He shouldn't, and to the extent that he needs to care about it in the current implementation, these are all issues with the usability of the current client.

Mostly likely the transaction wasn't included in the block due to some technical error in the way the miners' client chooses transactions. It's not due to malice on the miners' part.

Miners provide a service for a fee, it doesn't make sense to force them to provide a service to you. Ideally the incentive structure is designed in such a way that the market is efficient and you will find miners offering this service to you at a competitive rate. You're extrapolating from an occasional instance of a technical error, and your proposal does not solve the actual problems (which do exist, and for which a solution will have to be found).

Thank you. I almost started believing that it's not possible anymore to have a debate and disagree without everybody insulting eachother .

... sorry about that, sometimes i just gets too annoyed on stupid people. especially when they can't see the fatal consequences of a change that their think would make the network more efficient or fair.

WHAT? ME RENTING? ARE YOU TELLING ME TO STFU?

yes you are right, i should leave the topic now.

so you do not like people who told you that you fucked up, and your suggest sucks? Great! it is really productive. STUPID FUCK!

Thank you for helping me decide whether or not you should make it on my block list. I will also be grateful if you will ignore me too, there's no reason for us to interact anymore.

i will not control my language, when a STUPID FUCK like you comes and suggest a stupid change, without even learning how the stuff works now.

the blockchain will recover from the splits.
but you proposal would make many permanent splits in the blockchain, that it you not be able to recover from. every time someone does have a transaction that is not included in a block yet, it would reject it, while the rest of the network(that does not know about the tx), would continue to mine on the block that you consider invalid. and you would not be able to confirm more txs. 

a reorg will happen if the client receives a block with more total-work(sum of all the work done in all previous block), then the current one.
also how do you proof that a transaction took place before the block was mined?
the blockchain's function is to proof that at least some time have passed since something was made.

you are a STUPID FUCK, unless you are shutting your mouth now, and go learn how the stuff works now. then you may come back, and maybe i will talk to you in a more polite language.

I respectfully ask you to control your language. I don't think we grew up together, so a minimum of respect would help.

I understand what a block chain split is. I asked the rhetorical question because you implied that a split is very unlikely in the current state and very much likely in my proposal. I believe you are wrong, and my proposal doesn't make it much more likely to have splits.

I hope you agree that it is common sense to offer some guarantee that valid, accepted transactions will make it in a block in some reasonable amount of time. This is all I want to ensure. If zero fees are impossible - cool. If minimum fee needs to be higher - cool again. Minimum fee should be enforced for the users, but in turn the miners should also guarantee reasonable confirmation time.


I am sorry, I would have given a link to the tx, but I realized that I want that transaction kept private. I should have used another example . I am sure we can find another one, it's not the first time people complained about confirmation time. I don't know exactly how many blocks, but it was more than 24h, I don't think there were less than 4 blocks/h, so let's say a minimum of 80-90 blocks?


I used the standard client, I don't think that's the case.


As long as the system can guarantee that a transaction will be processed in a maximum amount of blocks, I have absolutely no problem with fees. The problem right now is that miners do have the means of ignoring a transaction if they want to. I simply don't think they should.

if you did read the next line, you would find out! STUPID FUCK! it would cause a block chain split. where half of the network would mine block upon the 'invalid' block. while the rest of the network would toss it away.

unless you understand how stuff works, please dont go posting about it.

What happens now and how does my proposal make it worse?

I paid the suggested transaction fee. I could not do anything to speed things up after my valid transaction was accepted. I (as a common user) don't know anything about input sizes, I just know that my transaction is not confirmed for more than 24h. Do you see the problem?


Are you suggesting that these attacks can't happen now? That these vectors are introduced by my proposal? Because if so, I believe you are wrong.


I paid suggested transaction fee. Why would a user care about how large it was (I assume you mean the number of inputs) and how many blocks? Why would a user care about blocks at all?


I did exactly what the Bitcoin client suggested I do. The system then ignored my transaction. And you don't see the problem? You will say it's a problem in the client, but I say that allowing the miners to ignore transactions indefinitely is the problem that should be fixed.

no! its a fucking bad idea. it sucks big time! NO!

Says who?  You?  The international agency on block protection?

It is a distributed network.  A miner has every right to mine.  Period.   Each individual miner has the right to include transactions they want in blocks.  It is entirely possible in the future there could be private hashing farms to support systems built on top of Bitcoin and they only hash their internal transactions.  

Increase your fee and stop being so cheap.  With Bitcoin you aren't guaranteed any level of service beyond what you pay for.  You want to pay bulk mailing rate and get priority overnight service.  The reality is you get what you pay for and as the network grows and block rewards decline that correlation between price and performance will only strengthen.

Also there are a lot of unintended consequences.  Your system would make transaction withholding more valuable and thus manipulatable. An unscrupulous miner could employe cancer nodes to fragment the network and prevent proper propogation.  Other miners would unknowingly be mining incomplete datasets and see higher rate of invalid blocks.  The beneficary would be the one doing the fragmenting.  You could even see a fragmentation arms race where various mining pools attempt to out do each other by degrading and delaying the network.  Not saying it will happen but you will create an incentive to fragment and destabilize the network.


How much did you pay and for how large of a transaction and how many blocks (not time) passed before your transaction was included?


I can't see a majority of miners working against their own best interest.  If miners excluded your transaction either they saw it as invalid (maybe a technical issue that your solution wouldn't fixed) or it wasn't in their interest (your fee didn't compensate them for the cost).  Make it in their interest and they will include it.  I don't see a problem that requires regulation.

well dude! make you own client that invalidates blocks that does not include fee-txs, and see how long it will survive.
what would happen if a tx only was broadcast to half of the network, and have not propagated enough?

half of the network would accept the block, and the other half would reject the block, and thereby causing a spilt! <- BAD THING.

I disagree. I think we can safely asume that mining nodes are well connected. Or they shouldn't be mining. I can think of no scenario where a mining node that's slow is useful to the network.


Totaly agree. Miners should be paid. All I'm asking is that they guarantee a reasonable transaction processing time. As I already said, if we need to drop free transactions, I'm all for it, but giving the miners the power to choose if a transaction will make it in a block or not, it's too much IMHO.

Bad idea.  You have no right to have a transaction included.  Let the free market decide.

How much was the fee and how large was the transaction?  I am guessing neglible and not so negligible respectively. 

I guarantee no miner is going to leave any sizable transaction fee behind.  You want express delivery pay express delivery prices.  If miners are dropping high value transactions then work with them.  It is likely a technical oversight. 

Tx propagation is fast in optimal conditions but you can't assume all nodes are aware of all transactions at all times, so you can't declare a block "invalid" just because it is missing a transaction. Also you shouldn't expect miners to do work for you unpaid, if you want them to include your transaction you should pay them for it. In fact to make the network secure it is important that enough is paid to miners, what we should be looking for is how to make transaction fees as high as possible while still being insignificant to the users.

That said, I do indeed believe, and have suggested in the past, that branch selection should involve more than just the total difficulty, and include things like the total bitcoin-days destroyed in the block - precisely to prevent denial attacks. But this needs to be much more subtle than just "reject a block if you know something it doesn't".

Also, you are drastically underestimating the hardware requirements a full network node will require if Bitcoin becomes successful.

I think there should be a feature where a transaction can be resubmitted with a higher fee.  And where nodes will recognize the second transaction (which looks like a double-spend) as a fee-increasing transaction.

I am not sure size is the main factor: not too long ago, I sent a transaction with 312 outputs to load lots of physical bitcoins, with no fee, and it went through promptly.  Then again, that transaction may look a lot more favorable compared to somebody combining a bunch of penny inputs (inputs take up much more space than outputs) - my big transaction only had a single input.