fornit



Offline



Activity: 987

Merit: 1001







Hero MemberActivity: 987Merit: 1001 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 03:33:52 AM #81 Quote from: solex on February 03, 2013, 10:55:56 PM An initial split ensuring "high or reasonable" fee transactions get processed into the blockchain within an average of 10 minutes, and "low or zero" fee transactions get processed within an average of 20 minutes might be the way to go.



Consider the pool of unprocessed transactions:



Each transaction has a fee in BTC and an origination time. If the transaction pool is sorted by non-zero fee size then: fm = median (middle) fee value.



[...]



The public would learn that low or zero fee transactions take twice as long to obtain confirmation. It then opens the door for further granularity where the lower half (or more) of the pool is divided 3, 4, or 5 times such that very low-fee transactions take half an hour, zero-fee transactions take an average of an hour. The public will accept that as normal. Miners would reap the benefits of a block limit enforced fee incentive system.



i doubt that transactions are that evenly distributed over a 24h or a 7day period. you might end up with all low-fee transactions bring pushed several hours, to times when rush hour is only for people living in the middle of the atlantic or pacific ocean.

which is imho perfectly okay for tips or micro-donations.



i doubt that transactions are that evenly distributed over a 24h or a 7day period. you might end up with all low-fee transactions bring pushed several hours, to times when rush hour is only for people living in the middle of the atlantic or pacific ocean.which is imho perfectly okay for tips or micro-donations. Mein deutsches Bitcoin-Blog - Guides, Nachrichten und Hurra-Journalismus!



Use Bitcoins to access all important filehosters for the price of one!

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW ertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 04:44:59 AM #82 Quote from: justusranvier on February 03, 2013, 08:47:03 PM Quote from: FreeMoney on February 03, 2013, 08:22:54 PM If space in a block is not a limited resource then miners won't be able to charge for it, mining revenue will drop as the subsidy drops and attacks will become more profitable relative to honest mining. How many business can you name that maximize their profitability by restricting the number of customers they serve?



If it really worked like that, then why stop at 1 MB? Limit block sizes to a single transaction and all the miners would be rich beyond measure! That would certainly make things more decentralized because miners all over the world would invest in hardware to collect the massive fee that one lucky person per block will be willing to pay.



Why stop there? I'm going to start a car dealership and decide to only sell 10 cars per year. Because I've made the number of cars I sell a limited resource I'll be able to charge more for them, right?



Then I'll open a restaurant called "House of String-Pushing" that only serves regular food but only lets in 3 customers at a time.

How many business can you name that maximize their profitability by restricting the number of customers they serve?If it really worked like that, then why stop at 1 MB? Limit block sizes to a single transaction and all the miners would be rich beyond measure! That would certainly make things more decentralized because miners all over the world would invest in hardware to collect the massive fee that one lucky person per block will be willing to pay.Why stop there? I'm going to start a car dealership and decide to only sell 10 cars per year. Because I've made the number of cars I sell a limited resource I'll be able to charge more for them, right?Then I'll open a restaurant called "House of String-Pushing" that only serves regular food but only lets in 3 customers at a time.

If car dealerships sold cars for however much you were willing to pay, down to and including free, you can bet they'd limit the number of cars they "sold". And I doubt you'd even get 10 out of them.



The problem is that we really don't know yet how to operate with the system we have, much less a different one. In a decade or two, when the subsidy is no longer the dominant part of the block reward, maybe then we'll have some idea how to price transactions, and we will be able to think clearly about mechanisms to adjust the block size. If car dealerships sold cars for however much you were willing to pay, down to and including free, you can bet they'd limit the number of cars they "sold". And I doubt you'd even get 10 out of them.The problem is that we really don't know yet how to operate with the system we have, much less a different one. In a decade or two, when the subsidy is no longer the dominant part of the block reward, maybe then we'll have some idea how to price transactions, and we will be able to think clearly about mechanisms to adjust the block size. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 05:00:22 AM #83 Quote from: kjj on February 04, 2013, 04:44:59 AM Quote from: justusranvier on February 03, 2013, 08:47:03 PM Quote from: FreeMoney on February 03, 2013, 08:22:54 PM If space in a block is not a limited resource then miners won't be able to charge for it, mining revenue will drop as the subsidy drops and attacks will become more profitable relative to honest mining. How many business can you name that maximize their profitability by restricting the number of customers they serve?



If it really worked like that, then why stop at 1 MB? Limit block sizes to a single transaction and all the miners would be rich beyond measure! That would certainly make things more decentralized because miners all over the world would invest in hardware to collect the massive fee that one lucky person per block will be willing to pay.



Why stop there? I'm going to start a car dealership and decide to only sell 10 cars per year. Because I've made the number of cars I sell a limited resource I'll be able to charge more for them, right?



Then I'll open a restaurant called "House of String-Pushing" that only serves regular food but only lets in 3 customers at a time.

How many business can you name that maximize their profitability by restricting the number of customers they serve?If it really worked like that, then why stop at 1 MB? Limit block sizes to a single transaction and all the miners would be rich beyond measure! That would certainly make things more decentralized because miners all over the world would invest in hardware to collect the massive fee that one lucky person per block will be willing to pay.Why stop there? I'm going to start a car dealership and decide to only sell 10 cars per year. Because I've made the number of cars I sell a limited resource I'll be able to charge more for them, right?Then I'll open a restaurant called "House of String-Pushing" that only serves regular food but only lets in 3 customers at a time.

If car dealerships sold cars for however much you were willing to pay, down to and including free, you can bet they'd limit the number of cars they "sold". And I doubt you'd even get 10 out of them.



The problem is that we really don't know yet how to operate with the system we have, much less a different one. In a decade or two, when the subsidy is no longer the dominant part of the block reward, maybe then we'll have some idea how to price transactions, and we will be able to think clearly about mechanisms to adjust the block size.

If car dealerships sold cars for however much you were willing to pay, down to and including free, you can bet they'd limit the number of cars they "sold". And I doubt you'd even get 10 out of them.The problem is that we really don't know yet how to operate with the system we have, much less a different one. In a decade or two, when the subsidy is no longer the dominant part of the block reward, maybe then we'll have some idea how to price transactions, and we will be able to think clearly about mechanisms to adjust the block size.

Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce. Why don't we just let miners to decide the optimal block size?If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

Jeweller



Offline



Activity: 24

Merit: 0







NewbieActivity: 24Merit: 0 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 06:39:40 AM #84 Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



Unfortunately it's not that simple for a couple reasons.



First, right now clients will reject oversized blocks from miners. Other miners aren't the only ones who need to store the blocks, all full nodes do even if they just want to transact without mining. So what if all the miners are fine with the 1-GB block and none of the clients nodes are? Total mess. Miners are minting coins only other miners recognize, and as far as clients are concerned the network hash rate has just plummeted.



Second, right now we have a very clear method for determining the "true" blockchain. It's the valid chain with the most work. "Most work" is easily verified, everyone will agree. "Valid" is also easily tested with unambiguous rules, and everyone will agree. Miners can't "simply drop" blocks they don't like. Maybe if that block is at depth -1 from the current block, sure. But what if someone publishes a 1GB block, then someone else publishes a 1MB block on top of that? Do you ignore both? How far back do you go to start your own chain and try to orphan that whole over-size branch?



I think you can see the mess this would create. The bitcoin network needs to operate with nearly unanimous consensus. Unfortunately it's not that simple for a couple reasons.First, right nowwill reject oversized blocks from miners. Other miners aren't the only ones who need to store the blocks, all full nodes do even if they just want to transact without mining. So what if all the miners are fine with the 1-GB block and none of the clients nodes are? Total mess. Miners are minting coins only other miners recognize, and as far as clients are concerned the network hash rate has just plummeted.Second, right now we have a very clear method for determining the "true" blockchain. It's the valid chain with the most work. "Most work" is easily verified, everyone will agree. "Valid" is also easily tested with unambiguous rules, and everyone will agree. Miners can't "simply drop" blocks they don't like. Maybe if that block is at depth -1 from the current block, sure. But what if someone publishes a 1GB block, then someone else publishes a 1MB block on top of that? Do you ignore both? How far back do you go to start your own chain and try to orphan that whole over-size branch?I think you can see the mess this would create. The bitcoin network needs to operate with nearly unanimous consensus.

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 07:07:09 AM #85 Quote from: Jeweller on February 04, 2013, 06:39:40 AM Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



Unfortunately it's not that simple for a couple reasons.



First, right now clients will reject oversized blocks from miners. Other miners aren't the only ones who need to store the blocks, all full nodes do even if they just want to transact without mining. So what if all the miners are fine with the 1-GB block and none of the clients nodes are? Total mess. Miners are minting coins only other miners recognize, and as far as clients are concerned the network hash rate has just plummeted.



Second, right now we have a very clear method for determining the "true" blockchain. It's the valid chain with the most work. "Most work" is easily verified, everyone will agree. "Valid" is also easily tested with unambiguous rules, and everyone will agree. Miners can't "simply drop" blocks they don't like. Maybe if that block is at depth -1 from the current block, sure. But what if someone publishes a 1GB block, then someone else publishes a 1MB block on top of that? Do you ignore both? How far back do you go to start your own chain and try to orphan that whole over-size branch?



I think you can see the mess this would create. The bitcoin network needs to operate with nearly unanimous consensus.

Unfortunately it's not that simple for a couple reasons.First, right nowwill reject oversized blocks from miners. Other miners aren't the only ones who need to store the blocks, all full nodes do even if they just want to transact without mining. So what if all the miners are fine with the 1-GB block and none of the clients nodes are? Total mess. Miners are minting coins only other miners recognize, and as far as clients are concerned the network hash rate has just plummeted.Second, right now we have a very clear method for determining the "true" blockchain. It's the valid chain with the most work. "Most work" is easily verified, everyone will agree. "Valid" is also easily tested with unambiguous rules, and everyone will agree. Miners can't "simply drop" blocks they don't like. Maybe if that block is at depth -1 from the current block, sure. But what if someone publishes a 1GB block, then someone else publishes a 1MB block on top of that? Do you ignore both? How far back do you go to start your own chain and try to orphan that whole over-size branch?I think you can see the mess this would create. The bitcoin network needs to operate with nearly unanimous consensus.

I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients.



Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block.



If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N 2 ), he will broadcast to the network and other miners will choose one between N and N 2 . Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N 2 . However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works)



Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so. I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients.Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block.If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N), he will broadcast to the network and other miners will choose one between N and N. Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N. However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works)Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 07:30:44 AM #86 Quote from: jl2012 on February 04, 2013, 07:07:09 AM I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients.



Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block.



If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N 2 ), he will broadcast to the network and other miners will choose one between N and N 2 . Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N 2 . However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works)



Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so.



What you are describing is much worse than a mere fork, the only word I can think of for it is a shatter. What you are describing is much worse than a mere fork, the only word I can think of for it is a 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 07:42:36 AM #87 Quote from: kjj on February 04, 2013, 07:30:44 AM Quote from: jl2012 on February 04, 2013, 07:07:09 AM I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients.



Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block.



If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N 2 ), he will broadcast to the network and other miners will choose one between N and N 2 . Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N 2 . However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works)



Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so.



What you are describing is much worse than a mere fork, the only word I can think of for it is a shatter.

What you are describing is much worse than a mere fork, the only word I can think of for it is a

This is actually happening and forces some miners to drop transactions from Satoshi Dice to keep their blocks slimmer. Ignoring big blocks might not be intentional but big blocks are non-competitive for obvious reason (take longer to propagate)



May be I should rephrase it:



Therefore, if the majority of miners are unable to handle the 1GB block N timely, they will keep building on N-1 until N is verified. Block N is exposed to a higher risk of orphaning, and building 1GB block will become very risky and no one will do so. This is actually happening and forces some miners to drop transactions from Satoshi Dice to keep their blocks slimmer. Ignoring big blocks might not be intentional but big blocks are non-competitive for obvious reason (take longer to propagate)May be I should rephrase it:Therefore, if the majority of miners are unable to handle the 1GB block N timely, they will keep building on N-1 until N is verified. Block N is exposed to a higher risk of orphaning, and building 1GB block will become very risky and no one will do so. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

Gavin Andresen





Offline



Activity: 1652

Merit: 1066





Chief Scientist







LegendaryActivity: 1652Merit: 1066Chief Scientist Re: The MAX_BLOCK_SIZE fork February 04, 2013, 05:17:08 PM #89 Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



I think this is exactly the right thing to do.



There is still the question of what the default behavior should be. Here is a proposal:



Ignore blocks that take your node longer than N seconds to verify.



I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.



Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.



Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."



Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).



I think this is exactly the right thing to do.There is still the question of what the default behavior should be. Here is a proposal:Ignore blocks that take your node longer than N seconds to verify.I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example). How often do you get the chance to work on a potentially world-changing project?

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 05:34:25 PM #90 Quote from: Gavin Andresen on February 04, 2013, 05:17:08 PM Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



I think this is exactly the right thing to do.



There is still the question of what the default behavior should be. Here is a proposal:



Ignore blocks that take your node longer than N seconds to verify.



I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.



Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.



Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."



Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).





I think this is exactly the right thing to do.There is still the question of what the default behavior should be. Here is a proposal:Ignore blocks that take your node longer than N seconds to verify.I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).

And if there are too many transactions than the available block space, people will pay more transaction fee and miner will have more money to upgrade their hardware and network for bigger block size. And if there are too many transactions than the available block space, people will pay more transaction fee and miner will have more money to upgrade their hardware and network for bigger block size. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

Akka



Offline



Activity: 1204

Merit: 1001









LegendaryActivity: 1204Merit: 1001 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 06:21:24 PM #92 Quote from: ShadowOfHarbringer on February 04, 2013, 06:13:24 PM This.



I am all for "let-the-market-decide" elastic algorithms.



If you let people select what is best for their interests, they will make the best choices through multiple tries in order to maximize profit & minimize risk.



Nobody wants to lose money, and everybody wants to earn the most. Therefore market will balance out the block size and reach perfect equilibrium automatically.



I concur,



a kind of "natural selection" in a open marked ends in the best possible solution for the current environment (hardware)



this also allows is to adapt to better hardware as there is no way to tell a 100% certain where development will go. (At least that's my opinion) I concur,a kind of "natural selection" in a open marked ends in the best possible solution for the current environment (hardware)this also allows is to adapt to better hardware as there is no way to tell a 100% certain where development will go. (At least that's my opinion) All previous versions of currency will no longer be supported as of this update

caveden



Offline



Activity: 1106

Merit: 1002









LegendaryActivity: 1106Merit: 1002 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 07:25:00 PM #94 Quote from: Gavin Andresen on February 04, 2013, 05:17:08 PM There is still the question of what the default behavior should be. Here is a proposal:



Ignore blocks that take your node longer than N seconds to verify.



That's nice. Just don't forget to include total download time in the "time to verify", as well as any other I/O time. Bandwidth will be a significant bottleneck once blocks start getting larger.



EDIT: Oh, and of course, there must be tolerance levels too (if I'm X blocks behind the chain I once rejected, I'll give up and start building on top of it). You don't want to create that many chain forks! That's nice. Just don't forget to include total download time in the "time to verify", as well as any other I/O time. Bandwidth will be a significant bottleneck once blocks start getting larger.EDIT: Oh, and of course, there must be tolerance levels too (if I'm X blocks behind the chain I once rejected, I'll give up and start building on top of it). You don't want to create that many chain forks!

arklan



Offline



Activity: 1778

Merit: 1008









LegendaryActivity: 1778Merit: 1008 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 07:25:34 PM #95 probably something ot aim to have in place before 1.0 is released... and since were closing in on .8... i don't post much, but this space for rent.

MPOE-PR



Offline



Activity: 756

Merit: 501









Hero MemberActivity: 756Merit: 501 Re: The MAX_BLOCK_SIZE fork February 04, 2013, 08:12:55 PM #96 Quote from: Gavin Andresen on February 04, 2013, 05:17:08 PM Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



I think this is exactly the right thing to do.



There is still the question of what the default behavior should be. Here is a proposal:



Ignore blocks that take your node longer than N seconds to verify.



I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.



Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.



Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."



Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).

I think this is exactly the right thing to do.There is still the question of what the default behavior should be. Here is a proposal:Ignore blocks that take your node longer than N seconds to verify.I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).

Spoken like a true Gavin. No objections. Spoken like a true Gavin. No objections. My Credentials | THE BTC Stock Exchange | I have my very own anthology ! | Use bitcointa.lk , it's like this one but better.

FreeMoney



Offline



Activity: 1246

Merit: 1011





Strength in numbers







LegendaryActivity: 1246Merit: 1011Strength in numbers Re: The MAX_BLOCK_SIZE fork February 04, 2013, 08:49:43 PM #97 Quote from: Gavin Andresen on February 04, 2013, 05:17:08 PM Quote from: jl2012 on February 04, 2013, 05:00:22 AM Why don't we just let miners to decide the optimal block size?



If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.



I think this is exactly the right thing to do.



There is still the question of what the default behavior should be. Here is a proposal:



Ignore blocks that take your node longer than N seconds to verify.



I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.



Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.



Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."



Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).





I think this is exactly the right thing to do.There is still the question of what the default behavior should be. Here is a proposal:Ignore blocks that take your node longer than N seconds to verify.I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults.Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant.Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network."Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example).

This rule would apply to blocks until they are 1 deep, right? Do you envision no check-time or size rule for blocks that are built on? Or a different much more generous rule? This rule would apply to blocks until they are 1 deep, right? Do you envision no check-time or size rule for blocks that are built on? Or a different much more generous rule? Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.