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.
Topic: 40 minute BTC block time - No big deal - page 2. (Read 6110 times)
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.
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.
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:
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 = (block_reward+fees) * (1 - e^(-(1/target block time)*delta_time)
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://bitcointalksearch.org/topic/m.3648359
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?
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.
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.
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:
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 = (block_reward+fees) * (1 - e^(-(1/target block time)*delta_time)
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://bitcointalksearch.org/topic/m.3648359
The whole thread is pretty interesting.
This does not seem to work.
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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?
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 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.
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?
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.
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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?
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.
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?
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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?
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"
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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.forcing miners to put junk in? how does that force miners to include tx?
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.sr. member
Activity: 448
Merit: 250
It's Money 2.0| It’s gold for nerds | It's Bitcoin
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.
again with these super long blocks
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. 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.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.legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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.
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.
Was there not just a 1 hour and 15 minute block a couple hours ago?
10m is an average waiting time , 40m is still in the control 
Jump to: