Insu Dra
|
|
June 13, 2013, 09:58:08 AM |
|
So we can conclude the 10-60 min for a 100% secure conformation is extremely fast compared to (none crypto) competition. And that adding extra bloat to block chain and network is simply not worth it ... (not cost effective at all)
It makes me wonder how the 2 min blocks affect max transaction per second as well ... I'm relatively sure faster blocks reduces the max amount of transactions per second but would need to do math to confirm that ... to lazy today.
|
"drugs, guns, and gambling for anyone and everyone!"
|
|
|
Prophet
Newbie
Offline
Activity: 36
Merit: 0
|
|
June 13, 2013, 01:54:25 PM |
|
The network is ultra secure. but we can definitely shave off some time down to 2 minutes would be way faster.
It would actually quintuple transaction maximum from 400k transactions per day to 400k max every 4 1/2 hours so we would have a daily transaction maximum of 2 million.
now if we consider that we will be cutting off modem users from the network and also people with slow connections it will cause an evolutionary pressure to upgrade, bonus. having that extra time for them does make it hard to overcome the network with a lightning fast propagation time but... if everyone has a gigabit connection then we would be increasing the confirmation security over the same 10 minute time period. the same hashing power in a smaller block time frame, statistical increase in security by the number of confirmations, the greater amount of hashing power will overcome anyone even with only 2 minutes of slack with a 25mbit connection.
and yes the authorization can be done instantaneously for paying for coffees and stuff, and it also makes it hard to do a low cost(sub $10) double spend attack within two minutes, those fast food places better have small lines.
|
|
|
|
jaywaka2713 (OP)
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
June 13, 2013, 06:02:07 PM |
|
There are some misconceptions going on right now. Every block is not submitted and added at the max block size. Not every block even hits that. So, if the block time is reduced by half to 5 minutes, then the blocks will have half the transactions, so half the block size. Bloat is not an issue. Block headers barely have data in them as it is. Also, if it is an issue, we can lower max transactions per block as well to insure less future bloat.
|
|
|
|
MWNinja
|
|
June 13, 2013, 06:37:42 PM |
|
If we don't do something like this we are effectively throwing away all of the additional compute power added by ASIC adoption.
|
|
|
|
julz
Legendary
Offline
Activity: 1092
Merit: 1001
|
|
June 14, 2013, 12:26:43 AM |
|
Bitcoin needs to be robust in the event of global internet bandwidth events which may cause congestion to regions or entire countries. Surely the 10 minute interval is a wiser choice from that perspective.
As there are alternative methods to come for ultra-fast settlement and off-chain microtransactions - (and due to random variations, a shorter block time wouldn't solve that issue anyway) I don't understand why people keep suggesting this change.
|
@electricwings BM-GtyD5exuDJ2kvEbr41XchkC8x9hPxdFd
|
|
|
Garrett Burgwardt
|
|
June 14, 2013, 12:52:41 AM |
|
If we don't do something like this we are effectively throwing away all of the additional compute power added by ASIC adoption.
I don't see any evidence that this is the case. As far as a faster confirmation, it seems that we're so far at least in agreement that very fast (<1 minute) blocks aren't ideal. I'd say that there's definitely an argument for 5 minute confirmations. Now, of course there's no additional security for n>6 transactions (if we're going to assume that 3 10 minute confirmations protect sufficiently from double spends). But incremental security is provided at low numbers of confirmations, for example, 1 5 minute confirmation is infinitely more secure than 0 confirmations under either timeframe. At 2 5 minute confs & 1 10 minute confirmation, security is the same and total block size is slightly increased (block headers). 3 5 minute confirmations is 1.5x as secure as 1 10 minute confirmation, and so on. This certainly isn't a critical need to change the confirmation time, but cutting the confirmation time in half could be argued to be worth the effort. My thoughts, anyway.
|
|
|
|
Eri
|
|
June 14, 2013, 12:58:13 AM |
|
its already been explained why faster blocks dont increase security. if the blocks come every 2 minutes then they are 4/5ths easier to make. that means 1/5th as secure. So rather then 6 confirmations youd need 30 to have the same security. Plus orphaned blocks would go up as a result. They would be 5 times more likely to happen. 10 minutes was chosen for a reason. It doesnt need to be smaller, its serves no purpose.
-future- When the block size increases to allow more transaction, were going to need that larger 10 minute block time to help reduce orphaned blocks. On my home connection i can move 1MB in a second, even if the blocks were 10MB it still wouldnt be an issue, it would merely take 10 seconds to move. I think its also fairly obvious that as time goes on people with dialup would be pushed out of the block generating business if anyone even uses dialup for this to begin with. By the time we end up with blocks at 10MB, were going to have pruning and at that point block size wont matter much. because all 'used' transactions will be removed anyway. We could even implement a torrent like behavior to help spread blocks across the network faster.
All in all, bitcoins future is bright and people worry over nothing.
|
|
|
|
Cubic Earth
Legendary
Offline
Activity: 1176
Merit: 1020
|
|
June 14, 2013, 02:21:09 AM |
|
its already been explained why faster blocks dont increase security. if the blocks come every 2 minutes then they are 4/5ths easier to make. that means 1/5th as secure. So rather then 6 confirmations youd need 30 to have the same security. Plus orphaned blocks would go up as a result. They would be 5 times more likely to happen. 10 minutes was chosen for a reason. It doesnt need to be smaller, its serves no purpose.
I'm not sure I agree. Wouldn't it be harder for an attacker to issue 5 2-minute blocks in a row than it would be for them to generate a single 10 minute one? I can see it being easier to make 5 2-minute blocks in a row than 5 10-minute ones, but I think what matters is expected security after x amount of time. After 30 minutes (approx. 15 blocks) with 2-min blocks you would be safer than 30 minutes with 10-minute blocks. Its like a serial dilution when you are rinsing something. Given a soapy jug and a one jug full of rinse water, if you just poured the rinse water into the soapy jug and then dumped it out there would be plenty of soap residue left (this being the 10 minute block). If you take the rinse water and add a pint at a time to the soapy jug, slosh it around, and dump it out, and then repeat that 8 times, the soapy jug will be very, very clean (this being the 1.125 minute block). The water is like our hashing power. There are more and less efficient ways to use its properties for our ends.
|
|
|
|
amincd
|
|
June 14, 2013, 04:55:22 AM Last edit: June 14, 2013, 04:06:43 PM by amincd |
|
I think a shorter block time would definitely be a little helpful to Bitcoin and I think we should target a 1 minute block time rather than 2 minutes. I'll collate my responses to common objections to a shorter block time: Faster blocks mean less security. You need 10 one-minute blocks to have as much security as one 10-minute block This is not true. The probability of solving a block will always be the same for a given hashrate, regardless of the block time. While some security is established by the amount of time required to get a confirmation, by increasing the cost to an attacker who is renting hardware to launch an attack, an attacker with a given hashrate* will have a much higher probability of double spending a 1-confirmation transaction in a 10 minute block-time chain than a 10-confirmation transaction in a 1 minute block-time chain. Meni Rosenfeld showed the math for this: https://bitcoil.co.il/Doublespend.pdf The trade-off is that with a higher rate of block generation, latency wastes more work, leading to lower difficulty for a >50% attack. For a POW network with a 135.03 TH/s hashrate like Bitcoin, the 10% decline in the difficulty of pulling off a >50% attack that would be caused by a change to a one-minute block time is probably tolerable, and worth the gain in more quickly secured transactions. *as long as it's not close to 50% of the network hashrate A one or two minute block time is still too slow for point of sale, so there's no point in adopting it. It's not enough for PoS, but in certain scenarios it would still be useful, like depositing BTC at an exchange or e-wallet that requires 1 confirmation to guard against corrupt miners which will permit 0-confirmation tx replacement for a fee. It leads to a transaction more quickly reaching the network's maximum level of confirmation security, at the cost, as mentioned, of decreasing the difficulty of a >50% attack. Changing the block time would violate what Bitcoin is supposed to be. What are we going to change next, the number of bitcoins issued per block? According to the bitcoin wiki, the prohibited changes to bitcoin's protocol are: https://en.bitcoin.it/wiki/Prohibited_changes- Increasing the total number of issued bitcoins beyond 21 million. Precision may be increased, but proportions must be unchanged.
- Changing the bitcoin distribution algorithm such that the subsidy at any given time period is decreased without miner consensus and 3 years notice, or increased beyond improved precision of halving (lossy beginning with block 1,890,000).
- Any rule that adds required, explicit centralization. For example, a change requiring that all blocks be signed by some central organization.
A technical improvement that doesn't change the 21 million coin limit and helps bitcoin better meet its initial design goal of being a "purely peer-to-peer version of electronic cash" which "would allow online payments to be sent directly from one party to another without going through a financial institution" does not change what makes bitcoin important and valuable.
|
|
|
|
Prophet
Newbie
Offline
Activity: 36
Merit: 0
|
|
June 14, 2013, 01:39:46 PM |
|
Remember what has been going on with feathercoin for the past while, they've been attacked by a 51% attack, it forked their client and started orphaning everyone elses transactions.
What are the examples from other Cryptocurrencies do we have to observe real world effects?
|
|
|
|
Eri
|
|
June 14, 2013, 02:15:47 PM |
|
If you pre mine a block and have it waiting until you buy something to release it to unspand the transaction, then yes a shorter block time would help in the sense the attacker would have less time to act. but in either case your talking about small amounts of money risking a large block reward if someone else finds the next block first. with the increase in orphaned blocks i really dont think its worth it.
an attacker could try to cheat the system of a small purchase, but it would be at the risk of losing the block reward that mining the block would give them.
just to throw some numbers out there. if you found a block and held it for an attack youd be risking 3250$(BTC25 x $130) to try to undo a transaction you just made, for anything under that dollar amount its simply not worth the attempt. for anything over, it will certainly require at least one confirmation. Not to mention, who would go into a store and attempt that transaction risking being arrested for fraud or theft. the number would have to be allot larger, ie if the transaction was the exact same value as the block reward then they have no incentive to try the attack, if the transaction was 2 times the size of the block reward they would have a 3250$ incentive to try it, and to risk jail. Again though, At that value who wouldnt require at least 1 confirmation?
This is why i really dont see it as a threat. i classify it as a non issue.
|
|
|
|
jaywaka2713 (OP)
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
June 14, 2013, 02:18:03 PM |
|
Remember what has been going on with feathercoin for the past while, they've been attacked by a 51% attack, it forked their client and started orphaning everyone elses transactions.
What are the examples from other Cryptocurrencies do we have to observe real world effects?
You also seem to misunderstand that the Bitcoin network is HUNDREDS of times faster than the feathercoin network. I could fork any of these brand new altcoins if I jump on first. Also, I don't think the shorter block time would be much of an issue anyways. I may not understand false transactions and double spends entirely, but wouldn't faster blocks make it HARDER for someone to double spend? The following statement is made with the assumption that the attacker does not have 51% of hashpower. If someone wanted to double spend, wouldnt they need to attack each and every block until the confirmations accepted by the seller are there? Can someone who thinks they have an adequate understanding of how the entire confirmation system works with security explain how it works? I feel as though some people here are slightly misguided. I also don't think the value of time is directly related to security. NOTE: I may not understand confirmations correctly. However, a 10 minute block's 1 confirmation compared to needing 10 1 minute block confirmations isn't correct. The correlation here is just time. 10 minutes goes by in each block time example. If time is how some of you are describing security, I doubt that is correct. I think 1 confirmation in a 10 minute block is as secure as 1 confirmation in a 5 minute block. However, I still need to understand how confirmation security really works.
|
|
|
|
amincd
|
|
June 14, 2013, 03:40:46 PM |
|
Remember what has been going on with feathercoin for the past while, they've been attacked by a 51% attack, it forked their client and started orphaning everyone elses transactions.
That had nothing to do with feathercoin's block time. With a 10 minute block time, an attacker would have needed a 3% higher hashrate to pull off the >50% attack, which would have been too small of a difficulty increase to prevent an attack. If you pre mine a block and have it waiting until you buy something to release it to unspand the transaction, then yes a shorter block time would help in the sense the attacker would have less time to act. but in either case your talking about small amounts of money risking a large block reward if someone else finds the next block first. with the increase in orphaned blocks i really dont think its worth it.
an attacker could try to cheat the system of a small purchase, but it would be at the risk of losing the block reward that mining the block would give them.
just to throw some numbers out there. if you found a block and held it for an attack youd be risking 3250$(BTC25 x $130) to try to undo a transaction you just made, for anything under that dollar amount its simply not worth the attempt. for anything over, it will certainly require at least one confirmation. Not to mention, who would go into a store and attempt that transaction risking being arrested for fraud or theft. the number would have to be allot larger, ie if the transaction was the exact same value as the block reward then they have no incentive to try the attack, if the transaction was 2 times the size of the block reward they would have a 3250$ incentive to try it, and to risk jail. Again though, At that value who wouldnt require at least 1 confirmation?
This is why i really dont see it as a threat. i classify it as a non issue.
An attacker can try to defraud a large number of parties at once. If the success-event reward is larger than the cost of executing a successful double spend, then it could be economical. A shorter block time also gives people a faster first confirmation. A single confirmation gives quite a bit more security than 0-confirmations, and would be enough for a lot of situations. Even when more confirmations are required, a shorter block time will make the process faster. Waiting six minutes instead of one hour for six confirmations is an advantage.
|
|
|
|
Garrett Burgwardt
|
|
June 14, 2013, 05:19:03 PM |
|
Can someone who thinks they have an adequate understanding of how the entire confirmation system works with security explain how it works? I feel as though some people here are slightly misguided.
I also don't think the value of time is directly related to security. NOTE: I may not understand confirmations correctly. However, a 10 minute block's 1 confirmation compared to needing 10 1 minute block confirmations isn't correct. The correlation here is just time. 10 minutes goes by in each block time example. If time is how some of you are describing security, I doubt that is correct. I think 1 confirmation in a 10 minute block is as secure as 1 confirmation in a 5 minute block. However, I still need to understand how confirmation security really works.
Confirmation eta is based on the target difficulty the bitcoin software determines. The higher the difficulty, the longer the time between confirmations (on average). So by making confirmations happen twice as often (every 5 minutes or so, ideally), the security granted by that confirmation represents half the work to secure your money (because the confirmation is easier to get, and thus an attacker could potentially "luck out" and get a block that much easier. Perhaps if you don't know how the system works, you shouldn't propose changes to the fundamentals of bitcoin
|
|
|
|
grue
Legendary
Offline
Activity: 2058
Merit: 1446
|
|
June 14, 2013, 05:25:48 PM |
|
I, a two year long Bitcoin user, have experienced the issues with the current 10 minute block time. There has been endless discussion about making zero-confirmation transactions safe, but what if a lighter solution is better? Why not reduce the block time? Now, I understand that a block time of 30 seconds does nothing but damage, and will not propose that, but what about a block time of 2 minutes? That will speed up transactions by 500%, and will make the hour-long transaction something of the past.
Hahahahha it doesn't work that way. Your transaction may confirm "faster", but it's in no way more secure. Not to mention all the extra orphans. If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation).
|
|
|
|
Garrett Burgwardt
|
|
June 14, 2013, 05:28:48 PM |
|
Even when more confirmations are required, a shorter block time will make the process faster. Waiting six minutes instead of one hour for six confirmations is an advantage.
That's not how confirmation security works, and it's been pointed out before in this thread.
|
|
|
|
jaywaka2713 (OP)
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
June 14, 2013, 05:35:31 PM |
|
Confirmation eta is based on the target difficulty the bitcoin software determines. The higher the difficulty, the longer the time between confirmations (on average). So by making confirmations happen twice as often (every 5 minutes or so, ideally), the security granted by that confirmation represents half the work to secure your money (because the confirmation is easier to get, and thus an attacker could potentially "luck out" and get a block that much easier. Perhaps if you don't know how the system works, you shouldn't propose changes to the fundamentals of bitcoin So if I understand you correctly, the higher the difficulty, the longer the confirmation eta? Does this mean that confirmations will get infinitely longer as time progresses? Also, I wasn't proposing a change to Bitcoin. I was simply starting a discussion about modifying factors that affect confirmations. Also, it's a wonderful opportunity to pick up more knowledge. Gotta learn somewhere, right? If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation).
Could you please provide a link to something explaining green addresses and off the chain tx? If you know enough about them, you are welcome to post here as well. I'd like to know more.
|
|
|
|
grue
Legendary
Offline
Activity: 2058
Merit: 1446
|
|
June 14, 2013, 05:38:21 PM |
|
Confirmation eta is based on the target difficulty the bitcoin software determines. The higher the difficulty, the longer the time between confirmations (on average). So by making confirmations happen twice as often (every 5 minutes or so, ideally), the security granted by that confirmation represents half the work to secure your money (because the confirmation is easier to get, and thus an attacker could potentially "luck out" and get a block that much easier. Perhaps if you don't know how the system works, you shouldn't propose changes to the fundamentals of bitcoin So if I understand you correctly, the higher the difficulty, the longer the confirmation eta? Does this mean that confirmations will get infinitely longer as time progresses? lolwut. difficulty makes it harder to get a block, but higher hash rate makes it easier. In short, the two are designed to cancel out to provide a consistent block time. If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation).
Could you please provide a link to something explaining green addresses and off the chain tx? If you know enough about them, you are welcome to post here as well. I'd like to know more. google kthx https://en.bitcoin.it/wiki/Green_address
|
|
|
|
jaywaka2713 (OP)
Sr. Member
Offline
Activity: 266
Merit: 250
aka 7Strykes
|
|
June 14, 2013, 05:41:24 PM |
|
Confirmation eta is based on the target difficulty the bitcoin software determines. The higher the difficulty, the longer the time between confirmations (on average). So by making confirmations happen twice as often (every 5 minutes or so, ideally), the security granted by that confirmation represents half the work to secure your money (because the confirmation is easier to get, and thus an attacker could potentially "luck out" and get a block that much easier. Perhaps if you don't know how the system works, you shouldn't propose changes to the fundamentals of bitcoin So if I understand you correctly, the higher the difficulty, the longer the confirmation eta? Does this mean that confirmations will get infinitely longer as time progresses? Also, I wasn't proposing a change to Bitcoin. I was simply starting a discussion about modifying factors that affect confirmations. Also, it's a wonderful opportunity to pick up more knowledge. Gotta learn somewhere, right? lolwut. difficulty makes it harder to get a block, but higher hash rate makes it easier. In short, the two are designed to cancel out to provide a consistent block time. I understand the concept of a stable difficulty. What Garrett Burgwardt said was that confirmation eta is based off of difficulty. He did not specify the difficulty/hashpower relationship. Based off his statement, as difficulty increases, confirmation eta increases. I certainly hope this isnt the case. Or he was incorrectly stating that the difficulty just simply makes it harder to confirm whilst keeping the 10 minute time. Thats probably so. My original suspicion about his statement is incorrect, and I now understand what he was saying.If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation).
Could you please provide a link to something explaining green addresses and off the chain tx? If you know enough about them, you are welcome to post here as well. I'd like to know more. google kthx Discussion is a beautiful thing.
|
|
|
|
calian
|
|
June 14, 2013, 05:47:12 PM |
|
If bitcoin is attacked would a 2 minute block time make mining via Tor or something similar difficult? Another minor point is that with block rewards 1/5 the size they will be by the current progression the rounding errors would start sooner and even less total coins would eventually be produced (assuming we don't add more than 8 places after the decimal point).
|
|
|
|
|