Author

Topic: Gold collapsing. Bitcoin UP. - page 1045. (Read 2032266 times)

legendary
Activity: 1764
Merit: 1002
August 06, 2014, 10:19:23 PM
i don't see that ever happening as long as Gavin remains lead dev.  there's no one even close to him that has the political capital, trust, or good will he has generated.
We'll see.

The reference client has already lost the technical lead to btcd, and their dev team is orders of magnitude more functional than Bitcoin Core's.

In addition, he doesn't have as much goodwill as you think. I'm not the only person who's noticed that there has been no substantial development in the reference client for about two years.

i can see that being true amongst other devs all of whom are desperately trying to make their mark or advocate for vested alternative interests.  but amongst the general users i think what i said holds.  i know it does from my perspective.
legendary
Activity: 1400
Merit: 1013
August 06, 2014, 10:06:39 PM
i don't see that ever happening as long as Gavin remains lead dev.  there's no one even close to him that has the political capital, trust, or good will he has generated.
We'll see.

The reference client has already lost the technical lead to btcd, and their dev team is orders of magnitude more functional than Bitcoin Core's.

In addition, he doesn't have as much goodwill as you think. I'm not the only person who's noticed that there has been no substantial development in the reference client for about two years.
legendary
Activity: 1764
Merit: 1002
August 06, 2014, 10:04:10 PM
btw,

nom, nom, nom, nom
legendary
Activity: 1764
Merit: 1002
August 06, 2014, 10:01:21 PM
what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?

he's already shown a reticence to not make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.
It may be the case that we don't get any protocol improvements until Bitcoin Core loses its monopoly on the full node network.

i don't see that ever happening as long as Gavin remains lead dev.  there's no one even close to him that has the political capital, trust, or good will he has generated.
legendary
Activity: 1400
Merit: 1013
August 06, 2014, 09:59:01 PM
what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?

he's already shown a reticence to not make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.
It may be the case that we don't get any protocol improvements until Bitcoin Core loses its monopoly on the full node network.
legendary
Activity: 1764
Merit: 1002
August 06, 2014, 09:57:52 PM
what i don't get is why isn't Gavin moving to increase block size now as opposed to when we're in the middle of the next bubble or two when tx size will have surely increased along with price and his back is against the wall?  i'm not advocating this, just asking the question.

he's already shown a reticence to make changes to the protocol.  not that i'm complaining, mind you, as i think he's done a stellar job as lead dev.  but at that point, it may be such a political hot potato that nothing may get done at all.  
legendary
Activity: 1400
Merit: 1013
August 06, 2014, 09:38:38 PM
tl;dr The protocol works very well and these considerations are baked in.  Bitcoin is quite secure in this regard.
So many people get caught up in the trap of "how will we make sure a market will arrive at the correct price for a service" without understanding that the question itself is invalid.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
August 06, 2014, 09:32:28 PM
Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*.
This situation does not exist.

The cost is very real and not-insubstantial - the increased orphan risk which you completely glossed over above.

The marginal cost can - and should - be brought very low but it will never reach zero.

The amount of transactions a miner can process in a ten minute interval is finite, therefore it is scarce, therefore the service of including transactions in a block will always have a price.

QFT!
The marginal cost decreases with the block reward proportionate to the mining fee.
So while the n vs n+1 will never be equivalent, they should be expected to increasingly approach the risk/reward for orphaning.
This should then also be expected to increase the desirability of including the n+1 transaction in the block.

At some future time the transaction fees may be more than the block rewards, as block sizes increase and the block rewards decrease.
This future time will likely be after a much longer term bitcoin price stability than anything in its history.  This may well be for younger people than I to observe.  
So far, bitcoin valuation has increased so much faster than block rewards decrease, and so transaction fees have decreased faster than block rewards.  We should not expect this to be true forever, just for a long time to come, and also for block sizes to increment over time.

tl;dr The protocol works very well and these considerations are baked in.  Bitcoin is quite secure in this regard.
sr. member
Activity: 364
Merit: 250
August 06, 2014, 09:11:11 PM
cypherdoc, I think this is the best thread ever.  What's the secret?  Running up a huge page count so that most new posters don't want to sift through all the info?

Somehow, present company excepted, this thread manages to attract thoughts and posts almost exclusively from thoughtful, knowledgeable, and thorough members.  It's my only real can't-miss thread every day.
legendary
Activity: 1162
Merit: 1007
August 06, 2014, 08:57:54 PM
Allowing the network to process more transactions at a lower cost is a good thing.

Agreed.
legendary
Activity: 1400
Merit: 1013
August 06, 2014, 08:35:26 PM
I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.
Of course they do, just like how McDonalds wants to reduce the marginal cost of cooking a Big Mac and a FedEx wants to reduce the marginal cost of shipping a package.

Allowing the network to process more transactions at a lower cost is a good thing.
legendary
Activity: 2324
Merit: 1125
August 06, 2014, 08:17:55 PM
Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.

I think it was Gavin who estimated the orphan cost per kB, and it was not insignificant.  I can't find the post off hand, but perhaps someone else can point us to it.  I'd like to be reminded of the actual numbers too.  

I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.  

Anyway, thank you both, I'll need to do some more reading/investigating on this. I'll check back here tomorrow whether someone did find that post Smiley
legendary
Activity: 1162
Merit: 1007
August 06, 2014, 08:12:59 PM
Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.

I think it was Gavin who estimated the orphan cost per kB, and it was not insignificant.  I can't find the post off hand, but perhaps someone else can point us to it.  I'd like to be reminded of the actual numbers too.  

I do know that the core devs want to reduce the orphan cost by propagating blocks by TX hash whenever possible.  High orphan costs are sometimes blamed for the hesitation of some miners to build larger blocks.  
legendary
Activity: 2324
Merit: 1125
August 06, 2014, 08:06:27 PM
Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

For example, is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that be including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat my by 25 seconds Smiley


Are these figures factual? I assumed the orphan chance to increase but only by a very small amount, small enough to completely ignore it. Does adding 500KB to a block really increase the orphan chances by 0.4%? I thought it would be many orders of magnitude less.
legendary
Activity: 1162
Merit: 1007
August 06, 2014, 08:03:26 PM
Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

Because of the orphan cost.  Each kB added to your block increases its propagation time and thus the probability that it will be orphaned.  

Consider the question "is it profitable to include another 500 kB of TXs (and keep the extra 0.1 BTC of fees)?"  The answer is "yes" only if the probability that your block isn't orphaned doesn't increase by more than 0.1/25 = 0.4%.  Imagine that by including the extra 500 kB, the chance that your block is orphaned increases by 1%.  This means that you'd lose 0.25 BTC on average by including the 500 kB of TXs.  Since those extra TXs only give you 0.1 BTC of fees, the answer is that you shouldn't include them.  

As internet speeds increase, the "orphan cost" goes down and it then becomes economical to accept a larger number of transactions.  

EDIT: I see JR beat me by 15 seconds.  My post had a larger word count and now it gets orphaned Sad
legendary
Activity: 1400
Merit: 1013
August 06, 2014, 08:03:11 PM
Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*.
This situation does not exist.

The cost is very real and not-insubstantial - the increased orphan risk which you completely glossed over above.

The marginal cost can - and should - be brought very low but it will never reach zero.

The amount of transactions a miner can process in a ten minute interval is finite, therefore it is scarce, therefore the service of including transactions in a block will always have a price.
full member
Activity: 151
Merit: 100
August 06, 2014, 07:54:44 PM
Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs.  

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  



Yes, a valid correction, and these are the reasons why block limits are still important.
legendary
Activity: 2324
Merit: 1125
August 06, 2014, 07:51:45 PM
Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

If we increase the limit every time we run into it we effectively have no limit.
legendary
Activity: 2324
Merit: 1125
August 06, 2014, 07:48:59 PM
If the transaction throughput was not limited in the original design the original design was flawed. Removing the transaction limit from Bitcoin could be it's undoing.

I've always found your posts insightful and I know that you are a very intelligent person; I'm interested in your rationale for keeping the blocksize static.  

The argument that "if the blocksize doesn't really matter, then why was a limit added?" seems valid to me.  A smaller blocksize also limits growth of the UTXO database, which is actually the more critical resource.  I'd like to see a healthy fee market develop along with a push towards off-chain transactions (perhaps using m-of-n Oracle sidechains).  A smaller blocksize would incentivize that.  That being said, Solex recently presented a helpful graphic that showed the increase in internet bandwidth since bitcoin's inception, indicating that 3MB blocks now would represent the same % of typically-available BW as 1 MB blocks did in 2009.  So the argument can be made that "we can safely increase the blocksize in parallel with internet speeds."  The Metcalfe value chart also shows a strong correlation between TXs per day and market cap, so an empirically-based argument can be made that limiting bitcoin's TX bandwidth would also limit its value.  

One point you made that I think is not valid is the notion that a 1 MB blocksize is a core part of the coin's definition (i.e., part of the "Satoshi Social Contract" in the same way the 21 M coin limit is).  There's plenty of evidence that indicates the 1 MB limit was never intended to be permanent.  Of course, this doesn't mean that it's necessarily a good idea to increase it without careful thought and debate either.  

Okay sure Smiley

For miners, the cost lies not in including transactions. Say the situation where a miner includes n transactions in a block or n+1 is equivalent in cost*. The cost for a miner lies in hashing the block with a nonce so the hash starts with a certain number of zeros (the difficulty).

Anyway, if I am a miner and I'm hashing away, I'm going to include every single transaction that pays any fee whatsoever in the block I'm hashing (if the block size is unlimited) simply because it costs me nothing to add the transaction and it does increase the amount I'm gaining when I find the right hash. Therefore, considering the situation with no size limit for a block and a set of rational miners all transactions will have a long term transaction fee of 1 Satoshi (or whatever the minimum unit is for the transaction in that time in the future).

Therefore the miners will receive payment of 1 Statoshi*the number of transactions for their job of securing the network and I believe this is insufficient as it would require 25*6*24/1^-8= 3.6*10^11 transactions daily to match the current block rewards. Granted, the exchange rate will increase in that time but not by a factor >10^6 (a factor 10^6 would imply $580M per Bitcoin).

Of course, in today's situation not all transactions are accepted even though we haven't touched the limit yet. This is because miners are not yet acting rationally but merely accepting the default recommended transaction fee guidelines proposed by the devs. This makes sense because the subsidy is still so high in comparison. It's a bit naive to think this situation will continue indefinitely though with an infinitely decreasing block subsidy.

Conclusion: for transaction fees to ever pay for the securing of the network a limit on the block chain is indispensable. Granted, this limit could have been larger than 1MB. However, if we increase it now, this will make it easier to increase it in the future as well because we create a precedent. As such it would continuously increase undermining the whole system. It would be like saying: we'll increase the maximum available Bitcoins to 100M. yes we'll only do it this once. Sure  Roll Eyes no-one will believe that.

The actual numbers may be arbitrary. Keeping them static however is far more important than people in this topic seem to realize.

Anyway, please tell me I'm wrong. I love being wrong Smiley. Please explain to me why anyone would pay a transaction fee above 1 Satoshi when the block subsidy has run out and the block size is not limited.

*I'm simplifying the situation here for number of transactions to be able to talk about it more naturally. It seems obvious the same holds for number of bytes in the block.
legendary
Activity: 1162
Merit: 1007
August 06, 2014, 07:45:22 PM
Sure, I'm not actually in favor of no limits either, but I am in favor of increased block sizes.

Me too.  

...right now there are minimum fees that all nodes enforce (not just miners) to prevent spamming….

This isn't quite right, and it's part of the worry.  A miner could mine a block that is 100% non-standard spam transactions regardless of fees and it would still be accepted as valid since nodes accept non-standards blocks and miners build on top of them.  Blocks #309657 and #309740 are proof of this.  The spam filters are achieved with the isStandard() method call and only prevent nodes from relaying transactions without the requisite fees or those that include dust outputs--these TXs can still get mined though.    

In case anyone's interested, currently about a third of the UTXO database is spam (a lot from SatoshiDice before the dust limits were implemented).  

Jump to: