40 minute BTC block time - No big deal

[p2pbucks]

10m is an average waiting time , 40m is still in the control 

[Ejaculation]

Was there not just a 1 hour and 15 minute block a couple hours ago?

[jonald_fyookball]

This use of "51%" for everything under the sun is staring to really get on my nerves.  51% has nothing to do with this - at all.

What if they had only 47, 48, 49 or 50% and decided to mine only empty blocks.  SAME DAMN THING:  on average about half the blocks would contain no transactions.

Not really.  a 51% attacker can mine 100% of the blocks if they want by establishing the longest chain.

[DannyElfman]

Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

[BurtW]

Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

This would increase the size of every copy of the blockchain and serve no purpose.

[Nerazzura]

Pretty interesting, to say the least. It's been a while since I've seen a really large block time, so I think it calls to ask: What could lead to such a long wait?

Receive almost instant payments with Bitcoin. However, there is an average delay of 10 minutes before the network starts confirm your transaction by entering the block and before you can use bitcoin you receive. A confirmation means that there is consensus on the bitcoin network that you received is not sent to the others and is still considered as your own. After your transaction has been entered in one block, it will continue to accumulate at the bottom of each block thereafter, which will exponentially consolidate this consensus and reduce the risk of aborted transactions. Each user is free to determine at which point a transaction has been confirmed, but the 6 confirmations are often considered to be safe as well as waiting 6 months on credit card transactions.

[APSJEX.com]

again with these super long blocks

[ShakyhandsBTCer]

Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

This would increase the size of every copy of the blockchain and serve no purpose.

The purpose would be to force miners to include a certain number of TX in every block they mine.

[BurtW]

Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

This would increase the size of every copy of the blockchain and serve no purpose.

The purpose would be to force miners to include a certain number of TX in every block they mine.

After thinking this over it sounds like it might just work.  What do some others (D&T, Greg, Gavin, etc.) think of this proposal?  I don't really see a downside to it off the top of my head.  It sounds reasonable to me, and most importantly, it does not appear to break any hardware, right?

[jonald_fyookball]

Seems a bit of stretch to try to apply political motivations to a technical issue.

It's also a stretch to propose that it's even technically possible at all to force miners to include transactions into blocks.

The Bitcoin code could be changed so that if a block is under a certain size (X Kb) then the miners must input "junk" data in the block to increase the size to X kb.

This would increase the size of every copy of the blockchain and serve no purpose.

The purpose would be to force miners to include a certain number of TX in every block they mine.

After thinking this over it sounds like it might just work.  What do some other's (D&T, Greg, Gavin, etc.) think of this proposal?  I don't really see a downside to it off the top of my head.  It sounds reasonable to me, and most importantly, it does not appear to break any hardware, right?

forcing miners to put junk in? how does that force miners to include tx?

[BurtW]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

[jonald_fyookball]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

[BurtW]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

Yes, the size of the block is directly related to the average orphaned block cost to the miner.  The reason this proposal works is that it increases the orphan cost across the board for all miners.

[jonald_fyookball]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

Yes, the size of the block is directly related to the average orphaned block cost to the miner.  The reason this proposal works is that it increases the orphan cost across the board for all miners.

Really? I thought I heard one of the devs saying it wasn't really true anymore. 
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

[DannyElfman]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

Yes, the size of the block is directly related to the average orphaned block cost to the miner.  The reason this proposal works is that it increases the orphan cost across the board for all miners.

Really? I thought I heard one of the devs saying it wasn't really true anymore. 
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

If it takes additional time for a pool to gather the TX and put them in the block when they find it, then there is a possibility that someone else could find a block and broadcast it to the network during that time. If a pool were to spend one additional second doing this then there would be a 1 in 600 chance that their block will be orphaned. 

[jonald_fyookball]

Because if the block has to be a certain size then they have to either pad it out to the required size OR put in paying transactions.  So rational miners will opt to fill out to the required size with fee paying transactions rather than just fill out with nothing.  Miners will think "might as well get the fees since the block must be the required size anyway"

There's already incentive to do that now.
"They might as well get the fees" already exists.

I may have missed something but is there any substantial (or even any at all)
mining advantage to minting blocks with fewer transactions with the current
structure?

Yes, the size of the block is directly related to the average orphaned block cost to the miner.  The reason this proposal works is that it increases the orphan cost across the board for all miners.

Really? I thought I heard one of the devs saying it wasn't really true anymore.  
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

If it takes additional time for a pool to gather the TX and put them in the block when they find it, then there is a possibility that someone else could find a block and broadcast it to the network during that time. If a pool were to spend one additional second doing this then there would be a 1 in 600 chance that their block will be orphaned.  

I don't think that is an accurate way to describe the process.
Miners don't "put transactions into a found block."
Instead, the block itself is solved based on the merkle root of all the transactions.

I do not know if miners are selecting a
new pool of transactions periodically or
not as they are hashing, or how long it actually
takes to select transactions and calculate the Merkle
root, but these factors would give an
indication of what the bottleneck would actually be.
If it only takes one millisecond, it may not be a substantial issue.

[APSJEX.com]

This does not seem to work.

[BurtW]

Really? I thought I heard one of the devs saying it wasn't really true anymore.  
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

I do not know if miners are selecting a
new pool of transactions periodically or
not as they are hashing, or how long it actually
takes to select transactions and calculate the Merkle
root, but these factors would give an
indication of what the bottleneck would actually be.
If it only takes one millisecond, it may not be a substantial issue.

Don't know which dev you were talking to.  The cost of larger blocks is due to the propagation delays associated with larger blocks.  The cost formula is:

First, RE: the orphan cost of transactions:  Decker/Wattenhofer measured 80ms for a 1K bigger block. The math to compute orphan cost is:

Code:

orphan cost = (block_reward+fees) * (1 - e^(-(1/target block time)*delta_time)

Plugging in 25 XBT block reward, 600 target time, 0.08 delta time, and assuming no fees (to make the math easier):

Code:

orphan cost = 25 * (1 - e^(-(1/600)*0.08) = 0.0033

So 3.3 mBTC per kilobyte is the orphan cost.

Note that the current default fees do not cover this cost.  In other words fees already should be higher in order to cover the marginal cost of putting a transaction in a block, thus increasing the size of the block.

You can read more here:

https://bitcointalk.org/index.php?topic=339505.msg3648359#msg3648359

The whole thread is pretty interesting.

[Marlo Stanfield]

Really? I thought I heard one of the devs saying it wasn't really true anymore. 
Maybe time for the experts to chime in as you suggested.
(certainly seems like a hard fork would be required.)

An additional point --  I assume the reason for the cost is that it
takes longer to calculate the merkle root, so instead of just stuffing
data in (and bloating the chain), some fixed data set could be
used to construct an alternate merkle root.

I do not know if miners are selecting a
new pool of transactions periodically or
not as they are hashing, or how long it actually
takes to select transactions and calculate the Merkle
root, but these factors would give an
indication of what the bottleneck would actually be.
If it only takes one millisecond, it may not be a substantial issue.

Don't know which dev you were talking to.  The cost of larger blocks is due to the propagation delays associated with larger blocks.  The cost formula is:

First, RE: the orphan cost of transactions:  Decker/Wattenhofer measured 80ms for a 1K bigger block. The math to compute orphan cost is:

Code:

orphan cost = (block_reward+fees) * (1 - e^(-(1/target block time)*delta_time)

Plugging in 25 XBT block reward, 600 target time, 0.08 delta time, and assuming no fees (to make the math easier):

Code:

orphan cost = 25 * (1 - e^(-(1/600)*0.08) = 0.0033

So 3.3 mBTC per kilobyte is the orphan cost.

Note that the current default fees do not cover this cost.  In other words fees already should be higher in order to cover the marginal cost of putting a transaction in a block, thus increasing the size of the block.

You can read more here:

https://bitcointalk.org/index.php?topic=339505.msg3648359#msg3648359

The whole thread is pretty interesting.

This doesn't seem to be going in a good direction for bitcoin. The transaction fees are getting too high too quickly. The block rewards are still high and adoption is just starting to take off.

High transaction fees combined with slow block times isn't very good. Wouldn't you agree?

[DeathAndTaxes]

The orphan cost is just an estimate and some other people (pool operators) have put the estimate at 50% to 90% less.   The protocol currently is rather inefficient.  For well connected nodes it would be possible to reduce the block message to just TxId which on average would reduce the orphan cost another ~95%.  If you reallllllly needed to reduce it more you could use reduced length hashes in the block message to reduce it 99.5% or more.  When you consider the cost of marginal bandwidth is continually dropping that means the orphan cost will also drop.   The orphan cost is also related to the subsidy and as the subsidy declines the orphan cost all declines.

So 3.3 mBTC is one estimate.  Other estimates are as low as 0.5 mBTC.  Lets look forward two years where available bandwidth has doubled, subsidy is halved and the protocol is using reduced length hashes in blocks (probably not necessary but since you seem worried).  That would be ~0.5 mBTC * 1/2 * 1/2 * 3/600 = 0.000625 mBTC per KB or ~6 satoshis.