Bitcoin Forum
November 18, 2017, 08:56:13 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Could preferring blocks with more txs help solve the small blocksize issue?  (Read 653 times)
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 22, 2013, 01:21:25 PM
 #1

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?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
1510995373
Hero Member
*
Offline Offline

Posts: 1510995373

View Profile Personal Message (Offline)

Ignore
1510995373
Reply with quote  #2

1510995373
Report to moderator
1510995373
Hero Member
*
Offline Offline

Posts: 1510995373

View Profile Personal Message (Offline)

Ignore
1510995373
Reply with quote  #2

1510995373
Report to moderator
1510995373
Hero Member
*
Offline Offline

Posts: 1510995373

View Profile Personal Message (Offline)

Ignore
1510995373
Reply with quote  #2

1510995373
Report to moderator
Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510995373
Hero Member
*
Offline Offline

Posts: 1510995373

View Profile Personal Message (Offline)

Ignore
1510995373
Reply with quote  #2

1510995373
Report to moderator
1510995373
Hero Member
*
Offline Offline

Posts: 1510995373

View Profile Personal Message (Offline)

Ignore
1510995373
Reply with quote  #2

1510995373
Report to moderator
niothor
Hero Member
*****
Offline Offline

Activity: 546


Niothor


View Profile WWW
November 22, 2013, 01:30:28 PM
 #2

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?


Wouldn't that involve a counter , and a value of min_time between blocks in each a larger block can take over?
This could get messy.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 22, 2013, 01:33:29 PM
 #3

Wouldn't that involve a counter , and a value of min_time between blocks in each a larger block can take over?
This could get messy.

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
niothor
Hero Member
*****
Offline Offline

Activity: 546


Niothor


View Profile WWW
November 22, 2013, 01:39:22 PM
 #4

Yeah , but there will be a lot of debate over the size , and the time between.
Overall a good idea, and could be implemented also the other way around  so we might avoid things like this:

https://blockchain.info/block-index/439289/0000000000000007df4a3fd95cc35eec4071e6a9e4dfa3dd81f0273cf3c2ffcd

Barek
Full Member
***
Offline Offline

Activity: 168


View Profile
November 22, 2013, 01:40:35 PM
 #5

I don't get why this gets brought up again and again.

Including a TX in a block costs the miner. If the fee outweighs the cost, it is in the miner's interest to include it. Otherwise, it is not.

A strong point about Bitcoin is that it does not need regulation, yet people seem to want to regulate the miners.
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 22, 2013, 01:44:25 PM
 #6

I don't get why this gets brought up again and again.

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

Including a TX in a block costs the miner. If the fee outweighs the cost, it is in the miner's interest to include it. Otherwise, it is not.

A strong point about Bitcoin is that it does not need regulation, yet people seem to want to regulate the miners.

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Sukrim
Legendary
*
Offline Offline

Activity: 2184


View Profile
November 22, 2013, 01:47:56 PM
 #7

Well, then you only incentivize miners to fill their blocks with as small as possible transactions using their own coins (with 0 fees) up to MAX_BLOCK_SIZE. This way it might be even better to reject a transaction and include 2 of your own instead. Also MAX_BLOCK_SIZE would be then EVERY_BLOCK_SIZE...

Of course that won't happen overnight, still it gives this incentive.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 22, 2013, 01:55:22 PM
 #8

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Sukrim
Legendary
*
Offline Offline

Activity: 2184


View Profile
November 22, 2013, 02:19:21 PM
 #9

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).
You can include fees too, though then you risk loosing the fees if you get forked off by other miners. Blocks that are not full would just get stuffed with "padding transactions" to win in fork situations, and more complex transactions would need an even higher fee, as they decrease transaction density.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
November 22, 2013, 02:28:30 PM
 #10

You can include fees too, though then you risk loosing the fees if you get forked off by other miners.

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?)

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Sukrim
Legendary
*
Offline Offline

Activity: 2184


View Profile
November 22, 2013, 10:22:24 PM
 #11

Depends on how you define "small" fee - if there are no magic constants (like the current minimum fee) a "small" fee can very well mean 1 Satoshi.

I guess there could eb an equilibrium of course, still it might very easily be somewhere in the area of "include padding in blocks" or if you adjust it slightly it might switch to "leave blocks deliberately (partially) empty" mode.
I don't think that miners really need incentives to mine 1 MB blocks other than fees. Maybe some better tools on selecting transactions etc. and filling their blocks might be of more use so they can execute more complex strategies.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
Pages: [1]
  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!