Bitcoin Forum

Almost everyone has seen the alternate currencies section of this forum. There has been just about one hundred coins developed, all with a variable range of block times. We have seen one benefit from this mass testing, and that benefit is faster block confirmation times.

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.

That 2 minute block time is long enough to prevent any orphans at all, and the network has been very well developed up to this point. However, changing the block time changes other things as well. One such example would be block reward. At the time of writing, the block reward is set to 25 BTC. So if the block time were to be changed to 2 minutes, the block reward would need to be changed to 5 BTC.

Yes, there are drawbacks to this change. One such drawback would have a direct effect on those who solo mine. Mining is really a game of chance. Cracking a block would only give you one fifth of the reward. There are also pros as well. This would allow pools to have higher odds in cracking blocks as well, as blocks are created 5 times faster. Block reward would continue to halve along with the current plan.

My main point is that transactions are simply too long. The one advantage the banking system has over us is instant transactions. Reducing the time required for about 6 confirmations from half an hour/hour to around 10 minutes would be very helpful. Also makes 1 confirmation transactions very fast as well. Thoughts?

I guess shorter time should be better. But I want to listen the opinion of the old members.

I too am very interested in their opinions. Block time is one of Bitcoins big issues for massive adoption, but is one of the easier issues to fix as well. The repercussions of such a change have to be discussed though.

EDIT: Fixed Poll. Yes/No were invalid answers to the question LOL.

Faster block conf times leads to a higher rate of orphaned blocks, increases the likelihood of dishonest folks from succeeding in double-spends in certain circumstances, and creates a larger blockchain.

A confirmation is not a guarantee of authenticity. Decreasing conf time proportionally decreases the "value" of the confirmation. Decreasing confirmation times would be accounted for in services requiring confirmations, where required confirmation times would be increased to completely negate the decreased conf times. (for example, Gox requires 6 confs -- reducing conf time to 5m would result in Gox requiring 12 confs)

... That said... to compromise the Bitcoin network back when the six-conf suggestion was suggested, it was dramatically less expensive to have double-spends confirm. Three confirmations is now more than adequate for all transactions under hundreds of thousands in USD. Going beyond is really just (inadequately) protecting yourself against a fork. Maybe it is time to discuss lowering the target conf time?

ETA: Devs may also be trying to encourage Bitcoin transactions to occur internally on central servers to keep "casual" transactions off the blockchain... OTOH, they seem to be in general consensus that the block size should be increased in the near future. I'm sure one'll come in soon and tell us what's up.

Actually, after the extensive testing of various altcoins, 2 minutes for a block time will not create many orphans at all, if any. After reading your post, it is obvious to myself that I do not fully understand what a confirmation is. Can you send me a link for me to read concerning confirmations?

You also said something about dropping the confirmation time. I was not aware such a variable existed. Would that decrease the integrity of the confirmations?

Sorry. I write like a shithead, sometimes.  :) I'll try to clarify some points I wrote particularly poorly.

When I was talking about expense to confirm double-spends, I was referring to the cost to compromise the Bitcoin network by making up a "dangerous" percentage of the total network hash rate. Network hashrate is dramatically higher now than when 6-conf suggestion was made (that is, when it was decided that 6 confirmations would be implied as "safe" by the Bitcoin client's graphics). It would likely cost millions, now, to get 3 confirmations on a double-spend, whereas it may've taken just a few thousand USD in hardware or hashpower leases far in the past. In this sense, the network is dramatically more secure, now, as it would be extremely expensive to successfully pass off a double-spend as legitimate through multiple block-solvings.

By conf time, I was just referring to the target confirmation time of a block (currently 10m). If you reduce it (say, to 5m), you are decreasing the amount of hash-power required to solve a block (exactly by half compared to what's required with a 10m target conf time). By doing so, it would be twice as easy to pull off a one-conf attack, which many would consider legitimate for smaller transactions. (but, again, this is still now prohibitively expensive even if it's twice as easy to pull off than now... one-conf probably won't be accepted as "legitimate" by most merchants selling something of significant value, so it's kind of a moot point).

The orphan argument I only picked up from others -- I haven't seen stats on it, so I'd take your word on it since I don't have any counter-examples.

ETA: Btw, don't consider me some type of authority on this stuff. I've always shied away from the technical underpinnings of BTC -- ADD, maybe. Bigger block sizes (more transactions allowed per block) might be considered a favorable option of ensuring speedy transaction processing because it doesn't introduce risks at all. Increasing block size 2x would have the same (eventual) effect as having 2x as many blocks, but wouldn't introduce the arguable risk of making merchants more vulnerable to one-conf double-spends (keeping in mind that one-conf double spends are 2x as computationally easy, and thus effectively 2x as cheap with half the conf time).

OK so if I understand you right, if we drop block time by half to 5 minutes, and doubled difficulty, would that keep the hashrate necessary stable? I'm not even sure that is correct, as I didn't think block time effected hashrate requirement to crack a block. Block time is just a variable correct? Or does block time tie directly into difficulty?

No it will only increase Bitcoins value and be beneficial.

Conf time is indirectly determined by difficulty, with difficulty roughly determining how many hashes are required to solve a block (thus, roughly how much time is required to solve a block).

Difficulty is determined by the target confirmation time (10 minutes) and the time it's taken to solve the past 2016 blocks. With 2016 blocks each with a target confirmation time of 10m, Difficulty should adjust about every two weeks, and is meant to adjust so it always takes roughly 10 minutes to solve a block. Because we're in a period of rapid network hashrate growth with the release of ASICs, it should actually take significantly less than 10 minutes to solve a block the closer we get to the next time difficulty corrects, but also means difficulty will correct sooner than the target of two weeks. (I'm sure someone has stats, but for the past month, it's probably been something like 10-12 days for each set of 2016 blocks instead of the target 14 days)

A target confirmation time of 5m instead of 10m would require halving the difficulty.

Trivia: Cryptocoins are subject to a kind of "spiral of death" if hashrate plummets. If, say, 75% of hash power dropped from the network a day after the difficulty is adjusted, it would take (13*3), or 39 days for difficulty to adjust to that sudden drop. Confirmations would take an excessively long time to confirm, possibly eroding faith in Bitcoin and causing a kind of "hash run," where even more hash power drops off until it's nearly impossible to confirm transactions anymore, leading to abandonment (or maybe some kind of fork).

Trivia2: Changing the target confirmation time is a protocol change and relatively difficult to have accepted.

Trivia3: I'm tired as dog-shit, and someone else should be much more able to assist you than I (and hopefully correct any misinfo I gave). Good night!

Harmful in the future

don't you need more confirmations to get the same security with shorter block times, also, I'm not sure how this would go for mass uptake

eg, when I shop, it takes the visa card about 1-3 seconds to confirm (its a pre-auth I think), and I am not sure a 1 sec is really possible with current tech, eg you would need 0.1 sec confirm to get 10 confirms and you still do have very poor security,

I may be wrong, but it a network propagation issue, that I think there is a solution by some sort....

I think it should be left alone 10Mins was what the creator had intended lets not start manipulating the code thats what alt coins are for, let them have this advantage at least e.g Litecoin with 2.5mins  :)

I've been thinking about this lately - the implications of block production time on security. It's discussed a bit in the following paper:

Rosenfeld, M. (2012). Analysis of hashrate-based double-spending, 1–14. Retrieved from https://bitcoil.co.il/Doublespend.pdf


Regarding orphans - someone mentioned that the time it takes a message to get from one end of the network to the other is 10 - 20seconds (don't know where that number comes from) but the indicator of how many orphans there are going to be is some function of the time it takes for a new block to propagate and the proportion that is of the block production rate.

e.g. 30 second block time, 30 second propagation time results in huge orphan rate.
10 minute block time, 2 second propogation time results in tiny orphan rate.

The issue of orphan transactions as well is slightly negated by quicker block production time.

e.g. it doesn't matter as much if your transaction gets orphaned once in a 30 second block rate, because it's only delayed by 30 seconds, but in a 10 minute block rate, that's 10 minute delay at least.

He also made Bitcoin in such a way where it could be modified if need be.

Kluge, your post made sense. So we can't double difficulty because that would double block time. So by halving difficulty that's what would effect the block time? Correct me if what I'm saying is wrong. If so, that shouldn't be the way to do this. I don't understand how the 5 minute block time affects the security of confirmations though.

With confirmation time, if we were to drop that value instead, would that leave us with a faster operating coin, or would it degrade confirmation quality?

Don't consider everything that Satoshi did as Law. I've been with the community for only a few months, but have dedicated 24/7 of my time to learn about it.

the system was built for experimentation, it is intentionally flawed to magnify certain weaknesses.

for example:

1 mb block limit was implemented = fee fluctuations can be seen when we saturate the block limit
                 
21,000,000 . 000, 000, 00 coins.  = exagerations in market fluctuations, movements caused by scarcity are more easily viewable and transferring economic data from currencies with large circulation values or extreme exchange values is cut off, at the front or back during the exchange process.

The code is extremely ambiguos, the core client was built in a very confusing manner, why?

It has a ton of features that are currently dormant and deactivated in the client, extreme flexibility would be a consideration for an experimental platform.


That 10 minute limit creates a global block saturation, everyone has the block before the next one is out even if they are running a modem connection, it even gives those 56k connections time to propagate the 1mb block, it protects against attacks from nodes with gigabit internet connections that are propagating their own preferred blocks and gives time for slower computers to confirm the hash from that block but to an exagerated level, attacks on the network are easily visible because of this architecture, it gives someone time to safely observe the attack, it is extremely exagerated 10 minutes is definitely a long time.

I would love to see confirmation time to go down and I think the network is mature enough to handle a five minute confirmation time, even 56kbp dial-up users would still be able to run a full node.

This is wrong, the 1-3 sec confirm from visa is the same as zero confirm in bitcoin in 99% of the cases. The amount of fraud due to this lack of conformation with visa and master card is just hidden and swept under the carpet, payed for with high transaction costs and interest by honest users. Your bank does not get true conformation until the money hits your real account (day's, if not weeks) and even then there are the charge backs ...

People need to stop thinking visa, master card are insta, there not ...

eu deposit cards on the other hand, "maestro" in particular does have centralized conformation system in matter of seconds. (but again also charge backs on top of that)

And Visa/MC are plagued with problems where an auth is not always removed after the charge does hit resulting in ability for the their customer to spend money, sometimes requiring several phone calls to clear it up.

This is true.  The 1 - 3 second time for credit cards is pretty much an authorization, not a confirmation.  I bought a domain name a couple months ago and had to do the actual purchase twice because the domain registrar I bought it from is German so my credit card company thought it was a fraudulent transaction even though the card got confirmed.  So the 1 - 3 second authorization isn't the same as a confirmation.

The fact people dont understand parts of bitcoin is common and people always see issues with it when they dont understand it.

Thankfully for a high degree of ability to work on bitcoin you need a high degree of understanding and trust by users that understand as well, otherwise you wont have anyone backing you.

Thankfully you cant just vote to have things magically changed. we have knowledgeable developers working on the client and giving us updates that knowledgeable members can verify for the rest of the users as to whether its a smart move or to scream like mad men if its some dastardly deed to undercut bitcoin.

If you want variation from the trusted and understood basics of what makes bitcoin, then by all means please make another altcoin.

Im not against change. But the way i see it, bitcoin has a path laid out for it. so far we havnt had major problems and were still implementing its basic functions and building up infrastructure. confirmation times are a non issue, if your moving 100K USD then you can afford to wait an hour since wire transfers can take days and cost allot more. if your buying a cup of coffee then a retailer can safely ignore confirmations. the weighted risk for profit against the risk for scam is excessively low to non existent and not financially viable.

The only things polls like these show, is the number of people that understand and the number that dont.

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.

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.

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.

If we don't do something like this we are effectively throwing away all of the additional compute power added by ASIC adoption. 

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.

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.

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.

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.

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:


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


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.


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.

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?

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.

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.

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.


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.

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 ;)

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).

That's not how confirmation security works, and it's been pointed out before in this thread.

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?


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.

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.

google kthx

https://en.bitcoin.it/wiki/Green_address

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).

From what I understand about Tor, yes it would make it more difficult. Shorter block times would cause more work to be lost to latency, which would affect those with slower connections more than others. Someone more familiar with Tor, and in particular Tor mining, should answer this though.


Good point. I think increasing the resolution of bitcoin amounts would be widely supported protocol change.

I don't know too many people in support of raising the 21 million possible Bitcoins.

That wouldn't increase the amount of bitcoins. It would only allow more precise decimal fractions of bitcoin to be transferred.

e.g. instead of being limited to transferring 5.23 uBTC, you would be able to transfer 5.2345678 uBTC.

Ohh, I misunderstood what you said. Yes, that will eventually happen if/when the satoshi or uBTC is worth something (e.g. $1)

I've explained in this thread why shorter block times do not increase the likelihood of an attempted double spend attack being successful, with the caveat that they make >50% attacks slightly easier and attacks using rented hardware less costly.

If I've missed something in my previous post:

https://bitcointalk.org/index.php?topic=232297.msg2470639#msg2470639

Please let me know.

*Edit, I guess one thing I haven't mentioned is that a shorter block-time block provides a smaller block reward and is therefore more expendable in an attack.

For example, if the block reward is 25 BTC for a 10 minute block, it would have to be reduced to 2.5 BTC for a 1 minute block. If you have 10% of the network hashrate, and were attempting to double spend transactions with 1 confirmation, you would have to give up 9 confirmations worth 225 BTC to successfully pull off an attack in the 10-minute blockchain, while you would only give up 22.5 BTC (9 X 2.5 BTC) in the 1-minute blockchain.

While this is all true, it's also true that the likelihood of an attacker successfully double spending a 10-confirmation transaction in a one-minute blockchain is much lower than an attacker successfully double spending a 1-confirmation transaction in a 10-minute blockchain, despite both putting the same amount of block reward at risk for the attacker and both taking the same amount of time.

Also, in many cases, people would be satisfied with much lower levels of security than that provided by one confirmation in a 10 minute blockchain, and could do with one or two confirmations in a 1-minute block-time chain.

The reason miners would resort to mining from Tor is that bitcoin would be under attack. If anyone connecting to the bitcoin network with a resolvable IP got the dreaded knock at the door then all miners would be mining through Tor.

I think it will probably be a while before we see this happen, but I do see it happening in the future as coins get harder and harder to obtain. Supply will be dwindling off while demand will be rising.

No, it's not "Discussion" when we're going over the same points over and over. It's just noise. If you can't show the courtesy of searching before posting, don't post.

But grueeeeeeeeeeeeeeee, using search takes too much work!

So, we agree that one ten minute confirmation represents x amount of work, yes? The way we'd have faster blocks (and thus confirmations) is to cut the amount of work required to find a block (on average). This is adjusted via the target difficulty (raise difficulty when average block time <10 minutes, lower difficulty when the average block takes more than 10 minutes to find).

So, when we make blocks happen faster, for example 10x faster (1 minute target blocks), difficulty is 1/10th the 10 minute difficulty (assuming it's a linear scale, don't recall offhand whether it is or not). This means that each block represents 1/10th the work to secure your money, and thus you need 10 1 minute confirmation to represent 1 10 minute confirmation.

So when you say we reach 6 confirmations ("max security"), you're saying that 6 1 minute blocks == 6 10 minute blocks, which as shown, is false. You have only 6/10ths the security of one 10 minute block, and only 1/10th the security of current "max security" (for all that means).




My bad, I wasn't precise enough explaining my thoughts (and how bitcoin works), and I certainly didn't mean to prevent you from thinking bitcoin over, it's just tiresome seeing the same threads over and over again with people who don't fully grasp the fundamentals of bitcoin. Unfortunately there's no really good place to learn other than to come up with ideas and hear why they're bad/won't work/etc :)

the current settings for bitcoin, the ten minute confirm times allows for the nodes to seattle any fork battles that may occur.

With a vpn and a terabit connection a major player can distribute a  double spend attack  while blocking pärt of the network with less than  50% hash power, effectivwly partitioning the network, in essence creating a perimeter of control. The 10 minutes allowes the slower network to reroute Their hashing power and overcome the speed advantage of propagating blocks.

A double spend attack has to reach a minimum of 6 confirmations,, with. 10% network hash power  that. Is  a  10%. Chance of getting a succesful fork, the next round drops to a 1% probability of keeping the fork. The attacker is now on a losing battle  to keep the reuse going; with larger % the attacker has dwindling probability of succesfully winning the next round.And all mining profits will disappear once they terminate the attack as the network begins to repair itself. That is a loss of 25 bitcoins  per block. So whatever they are stealing better be worth a lot, plus it can only be a p2p transaction with cash involved. 275 bitcoins is a lot of money.

The ten minutes guarantees that the fork is generated. A smart business would detect the double  spend  if the vpn was not creating a perimeter of control and even then the business would probably have their own vpn listening to world wide network transactions.

Sooner or later the network will repair itself  and most high ticket items require id, not to mention delivery time so you would have to play the odds for three weeks.

Difficulty would be the same regardless if its 2 minutes or an hour, it gets corrected every 2016 blocks

I agree with everything so far.


I disagree with this.

The likelihood of an attacker double spending a transaction with 10 one-minute confirmations is much lower than an attacker double spending a transaction with 1 ten-minute confirmation.

Security comes from the cost of executing a successful attack exceeding the payout from a successful attack. If the probability of an attack being successful is reduced, that means the cost of executing a successful attack increases, because it requires more attempts. Double spending a 10-one-minute-confirmation tx has the same payout for an attacker as double spending a 1-ten-minute-confirmation tx, but is harder (more costly) to execute.