Title: Blocksize increase vs. difficulty decrease Post by: jaked on May 11, 2017, 10:26:06 PM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size.
To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Title: Re: Blocksize increase vs. difficulty decrease Post by: XbladeX on May 11, 2017, 11:33:19 PM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? but if you lower diff and lets say you make from 10min 1min :) you will have 10x more coin inflation. 10min block is like it is , ETH have 16s blocks and carry like 120 000tx/day so timing is not that issue as inflation with block creation. ETH live with 16s block same as BTC with 10min :) with LN it would not matter at all. Title: Re: Blocksize increase vs. difficulty decrease Post by: kiklo on May 12, 2017, 04:00:30 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) Title: Re: Blocksize increase vs. difficulty decrease Post by: piloder on May 12, 2017, 04:07:30 AM Mining difficulty is not something that can be decreased by soft or hard fork, the number of miners and their respective mining power contributes towards mining difficulty. So the only way to decrease transaction fee and get faster confirmation is to increase blocksize.
Title: Re: Blocksize increase vs. difficulty decrease Post by: uneng on May 12, 2017, 04:14:45 AM Difficulty increasing is a rule and it can't be modified, it's like the rules of God for the world... In my vision miners are greedy and they want to mine fast to make profit fast even with high difficulty of mining.
They could continue mining on the same rhytm or waiting for better asics to mine faster, but somehow they don't need to charge so much from bitcoin users like now. That is what I think. Title: Re: Blocksize increase vs. difficulty decrease Post by: digaran on May 12, 2017, 04:28:43 AM I'm here to enlighten you son, let us assume difficulty decreases to 15,577.0 every body will keep mining 1 block every 10 minutes averagely if hashrate drops as well otherwise they'll mine every thing in matter of days and Wu could build an army of mercenaries to send after non BU lovers.
Also developers should start think about what happens if they hard fork? difficulty should decrease to avoid long time block finds. Remember Wu's army ought to take over Bitcoin, don't fall for their innocent faces. Title: Re: Blocksize increase vs. difficulty decrease Post by: jaked on May 12, 2017, 05:45:41 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) So let's, for the sake of argument, assume Core has those malicious motives, and take them out of the picture. Why is anyone else not proposing solutions based on faster blockspeed? Why don't we have a "BU" with a faster blockspeed, rather than larger block size? Title: Re: Blocksize increase vs. difficulty decrease Post by: Amph on May 12, 2017, 05:49:02 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) So let's, for the sake of argument, assume Core has those malicious motives, and take them out of the picture. Why is anyone else not proposing solutions based on faster blockspeed? Why don't we have a "BU" with a faster blockspeed, rather than larger block size? because would lead to more orhpan, there is a reason if the block time on average is 10 min, actuallyi t's better to say 2016 every two weeks and what you are proposing it's not feasible, it's based on miners decision, and the mining is done in a way that the more hash you have and the better which mean more diff this is done to make the network stronger to some various attacks, having the diff low mean less hash, which mean more insecure network Title: Re: Blocksize increase vs. difficulty decrease Post by: jaked on May 12, 2017, 06:14:39 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) So let's, for the sake of argument, assume Core has those malicious motives, and take them out of the picture. Why is anyone else not proposing solutions based on faster blockspeed? Why don't we have a "BU" with a faster blockspeed, rather than larger block size? because would lead to more orhpan, there is a reason if the block time on average is 10 min, actuallyi t's better to say 2016 every two weeks and what you are proposing it's not feasible, it's based on mienr decision, and the mining is done in a way that the more hash you have and the better which eman more diff this is done to make the network stronger to some various attacks, having the diff low mean less hash, which mean more insecure network Everything is based on miners's decisions, and hence everything is feasible. They could agree on a new protocol which reduces difficulty, in exactly the same way they could agree on a new protocol which increases the block size. A reduced difficulty reduces the security, but if BTC's value decreases due to scaling issues, the network's vulnerability increases as well, as hash power will be lost to other cryptos. Title: Re: Blocksize increase vs. difficulty decrease Post by: franky1 on May 12, 2017, 06:36:24 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? making blocks average to say 1minute means. that 12.5btc is made every 1min average instead of 10min average (or as amph notes 2016 blocks in 1.4 days instead of 14 days) which results in the reward halving event every 145 days instead of 4 years. which means all bitcoins will be mined in about 12 years as oppose to 120 years. so to mess around with reducing block reward to 1.25 for 1min blocks. and then mess with the reward halving and so on to correct things back to scale, takes alot more coding than you think.. plus breaking a lot more fundamental rules.. ALSO whether its 10 minutes or 1minute.. the people that say "10mins is too long" usually are buying things where even 1min would still be too long. EG queuing up at a grocery store checkout. standing there, waiting a minute is still too long. as many people know seeing someone count their change for 40 seconds instead of just swiping a card infuriates people. dont believe me. next time you are at a grocery store.. just stand there and do absolutely nothing for 60 seconds. and then look at the people behind you. dont beleive me. day trade on an exchange. see a good price and instead of hitting the order button.. just sit there for 60 seconds.. and then look to see if the good offer is still there. now when it comes to data movement. whether its 4032 blocks of 1mb each a month.. 4032 blocks of 10mb each a month whether its 4032 blocks of 1mb each a month.. 40320 blocks of 1mb each a month the bandwidth of both 'more data' is the same 40gb and anyone complaining about internet data caps will still run into the same problem and as other have mentioned if blocks are being created once a minute, by the time they get passed to a node, verified, passed to another node, verified (the relay propagation) this can cause alot more congestion, orphans, rejects and other issues. this is where pools who think they have won the fastest block, realise someone else beat them by milliseconds, and as such they end up wasting time and not getting as much income.. Title: Re: Blocksize increase vs. difficulty decrease Post by: Qartada on May 12, 2017, 06:47:51 AM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) So let's, for the sake of argument, assume Core has those malicious motives, and take them out of the picture. Why is anyone else not proposing solutions based on faster blockspeed? Why don't we have a "BU" with a faster blockspeed, rather than larger block size? because would lead to more orhpan, there is a reason if the block time on average is 10 min, actuallyi t's better to say 2016 every two weeks and what you are proposing it's not feasible, it's based on mienr decision, and the mining is done in a way that the more hash you have and the better which eman more diff this is done to make the network stronger to some various attacks, having the diff low mean less hash, which mean more insecure network Title: Re: Blocksize increase vs. difficulty decrease Post by: el kaka22 on May 12, 2017, 07:44:31 AM There were proposals of introducing new types of blocks with no reward but only for the purposes of verifying transactions in between actual blocks. 10 minute blocks with rewards will remain intact as usual but new types of blocks was proposed to be generated on every one or two minutes just to confirm the transactions still miner's hash contribution should be taken for consensus for rewarding the new bitcoins as per existing manner. But I did not hear any update on this to get implemented or not.
Title: Re: Blocksize increase vs. difficulty decrease Post by: ralle14 on May 12, 2017, 08:45:41 AM I also think decreasing the difficulty won't have the same effect because like what franky1 said it will speed things up and will ruin the countdown of the block reward halving. Let's say they reduced the difficulty, if the miners still follow the countdown regardless of the blocks mined they would obviously still mine more than 210,000.This would also lead miners to mine more empty blocks. I think those could be the reasons why there's no fork for decreasing the difficulty of mining.
Title: Re: Blocksize increase vs. difficulty decrease Post by: d5000 on May 12, 2017, 11:54:49 AM I also think decreasing the difficulty won't have the same effect because like what franky1 said it will speed things up and will ruin the countdown of the block reward halving. If you wanted to reduce the block time target, let's say, to 1 minute, then you obviously can do the following: - replace DifficultyTarget by DifficultyTarget/10 - replace BlockReward by BlockReward/10 - replace NextHalvingBlockHeight by HardForkBlockHeight + ((OldNextHalvingBlockHeight - HardForkBlockHeight) * 10) and you will have, approximately, the same halving schedule and the exactly same coin supply. The reason why block times are not reduced is actually, as some have already said, the higher orphan rate, that would lead to a less efficient system. But there is some research done in this topic, so it's not sure it won't be implemented at some point in the future if orphan rate can be decreased by technical improvements. and use LN to make BTC into an Offchain Fractional Reserve banking system. How would that be possible? AFAIK LN would not allow "fractional reserve" and that's the advantage it has over centralized off-chain solutions like Coinbase. Title: Re: Blocksize increase vs. difficulty decrease Post by: dinofelis on May 12, 2017, 02:38:13 PM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Why not simply use the chain that is exactly like bitcoin, but does that, and is called LTC ? Litecoin runs 4 times faster than BTC, has (hence) 4 times more room on the chain, is (hence) 4 times quicker in confirmation ; and hey, it even got Segwit even though that doesn't serve any purpose for the moment on an essentially empty chain. It sounds like people are complaining that each time they buy, say, a Ford-T it doesn't have this and it doesn't have that. I'd say, go to the dealer next door, who sells Toyota. Maybe it is a product that has the things you want ? Title: Re: Blocksize increase vs. difficulty decrease Post by: DooMAD on May 12, 2017, 02:56:57 PM I also think decreasing the difficulty won't have the same effect because like what franky1 said it will speed things up and will ruin the countdown of the block reward halving. If you wanted to reduce the block time target, let's say, to 1 minute, then you obviously can do the following: - replace DifficultyTarget by DifficultyTarget/10 - replace BlockReward by BlockReward/10 - replace NextHalvingBlockHeight by HardForkBlockHeight + ((OldNextHalvingBlockHeight - HardForkBlockHeight) * 10) and you will have, approximately, the same halving schedule and the exactly same coin supply. The reason why block times are not reduced is actually, as some have already said, the higher orphan rate, that would lead to a less efficient system. But there is some research done in this topic, so it's not sure it won't be implemented at some point in the future if orphan rate can be decreased by technical improvements. Well, the orphan rate plus the unfortunate potential consequence of the total overall blockchain growing rapidly in size. A fair assumption is that the average block would be a bit smaller if it were faster because less transactions would be queuing, but if more spam got included and we (hypothetically) averaged 0.3 or 0.4 MB blocks every minute, that's a pretty hefty size increase over time compared to a maximum of 1MB every 10 minutes. You could offset this by also reducing the max blocksize, but then it doesn't allow for more transactions. and use LN to make BTC into an Offchain Fractional Reserve banking system. How would that be possible? AFAIK LN would not allow "fractional reserve" and that's the advantage it has over centralized off-chain solutions like Coinbase. It's noble of you to try, but kiklo isn't listening to reason on that front. Believe me, I've made multiple attempts to explain why he's wrong, but he keeps repeating it regardless. LN is fractional reserve, up is down and the sky is green with purple spots. That's just how things are in kiklo's world, heh. Title: Re: Blocksize increase vs. difficulty decrease Post by: Amph on May 12, 2017, 03:23:42 PM In the ongoing scaling debate, I wonder why is the discussion focused solely on the block size. To my understanding, decreasing the difficulty, either statically or dynamically, has the same effect, of increasing the transaction-confirmation rate. I don't know if such a thing can be done with a soft work, but for those advocating a hard fork, why not a fork that decreases difficulty? Can anyone enlighten me? Bitcoin Transaction Capacity could have been increased by a larger block size or a faster blockspeed. Either would work. BTC Core is blocking all improvements for 1 reason to push shitwit, and use LN to make BTC into an Offchain Fractional Reserve banking system. Increasing transaction capacity would allow people to keep their transactions onchain, keeping the transaction capacity pathetic like it is now forces people to use their offchain fractional reserve bullshit. In Short BTC Core makes money by selling BTC out forever to the banking cartels. 8) So let's, for the sake of argument, assume Core has those malicious motives, and take them out of the picture. Why is anyone else not proposing solutions based on faster blockspeed? Why don't we have a "BU" with a faster blockspeed, rather than larger block size? because would lead to more orhpan, there is a reason if the block time on average is 10 min, actuallyi t's better to say 2016 every two weeks and what you are proposing it's not feasible, it's based on mienr decision, and the mining is done in a way that the more hash you have and the better which eman more diff this is done to make the network stronger to some various attacks, having the diff low mean less hash, which mean more insecure network Everything is based on miners's decisions, and hence everything is feasible. They could agree on a new protocol which reduces difficulty, in exactly the same way they could agree on a new protocol which increases the block size. A reduced difficulty reduces the security, but if BTC's value decreases due to scaling issues, the network's vulnerability increases as well, as hash power will be lost to other cryptos. it doesn't make sense to change the code to reduce the diff while the hash is the same, the diff is based on the hash, otherwise you are changing the way the diff is displayed but the real one would always match the hashrate in any case no miner will ever agree to reduce his/her hashrate and take less profit, this is utterly no-sense, and i don't think that the value will decrease because of scalability issue the majority of people that buy bitcoin just don't use their coins they put them in holding, therefore they don't need lower fee, i bet only those that at the moment need this are average joe moving 0.01 every week or so... |