Bitcoin Forum
December 07, 2016, 12:54:20 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Idea: new rules for block validation  (Read 3319 times)
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 01:26:48 PM
 #1

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?
1481115260
Hero Member
*
Offline Offline

Posts: 1481115260

View Profile Personal Message (Offline)

Ignore
1481115260
Reply with quote  #2

1481115260
Report to moderator
1481115260
Hero Member
*
Offline Offline

Posts: 1481115260

View Profile Personal Message (Offline)

Ignore
1481115260
Reply with quote  #2

1481115260
Report to moderator
1481115260
Hero Member
*
Offline Offline

Posts: 1481115260

View Profile Personal Message (Offline)

Ignore
1481115260
Reply with quote  #2

1481115260
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481115260
Hero Member
*
Offline Offline

Posts: 1481115260

View Profile Personal Message (Offline)

Ignore
1481115260
Reply with quote  #2

1481115260
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
November 28, 2011, 01:35:40 PM
 #2

* 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).

I wonder what you will do about the blockchain being 25920 megabytes larger 181 days from now?
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 01:45:50 PM
 #3

* 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).

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

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.
jwzguy
Hero Member
*****
Offline Offline

Activity: 868



View Profile
November 28, 2011, 01:57:20 PM
 #4

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.


19wXnWTeGuraN9g5UsMAi119sWzDCQcr7S
Bitcoin Logo shirts!
evorios
Jr. Member
*
Offline Offline

Activity: 30


View Profile
November 28, 2011, 02:12:53 PM
 #5

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.
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 02:23:02 PM
 #6

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.

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.
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 02:26:18 PM
 #7

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.

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.
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
November 28, 2011, 02:27:54 PM
 #8

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

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 02:41:39 PM
 #9

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

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 Smiley. 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.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
November 28, 2011, 02:41:52 PM
 #10

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.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 1890



View Profile WWW
November 28, 2011, 03:54:39 PM
 #11

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
November 28, 2011, 04:04:16 PM
 #12

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. 
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 04:09:36 PM
 #13

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.

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.

Quote
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.

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.
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
November 28, 2011, 04:13:15 PM
 #14

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
November 28, 2011, 04:14:50 PM
 #15

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.

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.

Quote
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.

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.

kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
November 28, 2011, 04:23:48 PM
 #16

but I would be interested to hear what you think about the general idea?
no! its a fucking bad idea. it sucks big time! NO!

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 04:41:32 PM
 #17

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.

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?

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.

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.

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

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?

Quote
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 or it wasn't in their interest.  Make it in their interest and they will include it.  I don't see a problem that requires regulation.

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.
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 04:42:19 PM
 #18

what would happen if a tx only was broadcast to half of the network, and have not propagated enough?

What happens now and how does my proposal make it worse?
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
November 28, 2011, 04:49:53 PM
 #19

what would happen if a tx only was broadcast to half of the network, and have not propagated enough?

What happens not and how does my proposal make it worse?
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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
ovidiusoft
Sr. Member
****
Offline Offline

Activity: 252


View Profile
November 28, 2011, 05:04:01 PM
 #20

Well you paid the minimum fee and got minimum service.  So what is the issue?  Did the client promise any level of service which wasn't met?  Did it indicate that it would be included in the next block guaranteed?

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.

Quote
You still didn't indicate how large the transaction was nor how small the fee was nor how many blocks passed (miners have no control over time only blocks).
If you don't want to give any technical details on the transaction in question that is fine but I will stick the consensus so far that your proposal is flawed.

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 Sad. 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?

Quote
You also seem to completely ignore the fact that this may be a TECHNICAL problem that miners (or maybe even some node thus miners never even saw it) considered the transaction invalid and thus excluded the transaction for non-fee reasons.  Setting fee rules wouldn't solve that problem it would actually create further issues as some nodes wouldn't broadcast the transaction thinking it is invalid and some node would consider the block invalid because it didn't include the transaction.

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

Quote
Higher fee would result in higher service.

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.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!