Suggested MAJOR change to Bitcoin

[kano]

OK, anyone who has dealt with any of the recent scamcoins (especially LTC) will have noticed one big scamcoin advantage that shows why Bitcoin will never be adopted in a big way:
transaction confirm times.

Simply put, a 5 transaction confirm is regularly over an hour (especially during the recent excessively slow difficulty readjustments - slow due to the code design ignoring the reality of the recent down turn)

Yet there is a reasonably straight forward solution that has a collection of advantages and only one disadvantage:

My solution: decrease the block time to 2 minutes and decrease the block payout to 10 bitcoins.

The one disadvantage: more blocks in the block chain - however this doesn't actually mean that the blockchain will become 5 times larger, it just means there will be 5 times the number of basic block headers (80 bytes) and more data due to there being more (smaller) merkle trees.
In terms of transactions, it will, of course, make no difference - the transactions themselves will just be distributed across the blocks.

It has been made clear by most people around here (including Gavin) that namecoin mining adding an extra 46 bytes per block for no advantage to Bitcoin at all, is considered 'nothing' - so those people would have a tough time arguing that this change that is of great advantage to Bitcoin with a small size increase in the block-chain is bad due to the size increase.

Now for the advantages:
1) The overall total coin production will remain the same (yes of course the code would halve it to 5 then 2.5 then 1.25 etc as before)

2) The overall average rate of coin production will be the same

3) If you want to argue why 10 minutes per block times 5 confirms is better then you just wait 2 minutes per block times 25 confirms and get that same warm fuzzy feeling

4) If you prefer to only have an average 10 minutes to wait per transaction, you can rest assured that it is possible with 5 confirms of lower difficulty blocks (which, by the way, everyone was happy with that lower difficulty confirmation last year - why not this year?)

5) There will be lower variance in block confirms which will also mean there will be lower variance in payout in smaller mining pools and thus fewer small mining pools will fail unlike what has been happening over the last few months.

6) There is the current issue I have already mentioned in another thread that will be mostly resolved by this also ... i.e. I'm suggesting that retargets would still occur every 2016 blocks or in the new case, once every 2.8 days since it's the number of blocks that determines the validity of the retarget, not the amount of time (I don't agree that 2016 was necessary, but anyone who thinks it is, well 2.8 days = 2016 blocks with this change)

Now where did I get the idea form?
Simple: watching and waiting for LTC transactions vs never bothering to watch/wait for BTC transactions (coz they are so damn slow)

Again, I can really only see two arguments about this (that I have already mentioned some details above)

1) Increase in data in the block-chain (not a 5 times increase - WAY way less)

2) Decrease in confirm security if people want to use 5 confirms (back to the security of BTC last year)

Of course this change will mean a fork with a specified future block at which point it will take place.

Discussion/Comments anyone?

And please give reasons for or against.

[1713878002]

1713878002

[1713878002]

1713878002

[1713878002]

1713878002

[1713878002]

1713878002

[dogisland]

For those that didn't know what LTC is (as I didn't) http://litecoin.org/

And for why we use 10 minutes currently https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F

Personally I think it's a good idea.

[blueadept]

I thought the biggest reason blocks are supposed to be generated no less than 5 minutes apart was in preparation for much higher network volume, which would increase block propagation time?  The rest of the points you make are valid AFAIK.  If you're really looking for security in no-confirmation transactions, an open-source version of something like transactionradar.com (with some additions) might work instead of changing Bitcoin altogether.

Imagine a node that's "well-connected" - connects to many other nodes in the Bitcoin network, as well as to as many miners as it can.  When it gets a transaction, it does an extra set of checks by requesting the transaction from each mining node it knows about.  As soon as a large percentage of the mining nodes (by number or, preferably, by hashing power) have accepted the transaction, it could be considered as on the way to confirmation.  This would only work for small transactions that you don't mind having a very small chance of being double-spent.  For higher value transactions, you wait until the transaction is in a block and has a number of confirms growing (logarithmically?) with the value of the transaction before you consider it good.

[wareen]

I'm absolutely in favor of this - 10 minutes is really too far on the conservative side.

Of course, this would be a huge change and might sound scary but I don't see any compelling reasons why we shouldn't do this, since it has been more or less proven to work with the alternate coins.

Especially the reduction of mining centralization would be a big advantage IMHO - it is arguably not healthy for Bitcoin to have 2/3 of the mining capacity being controlled by just two pools. Having more frequent blocks, mining solo is much more attractive.

It would also reduce the window of opportunity for Finney attacks.

Of course we would see reorgs more often and miners with slower Internet connections would have a slight disadvantage. Another disadvantage is that the core rules of Bitcoin would be changed, thereby somehow breaking the contract we all agreed to when we joined Bitcoin. But overall I think the advantages outweigh and it would greatly improve Bitcoin's user experience.

[dogisland]

As soon as a large percentage of the mining nodes (by number or, preferably, by hashing power) have accepted the transaction, it could be considered as on the way to confirmation.

That would be great as part of some sort of Bitcoin instant payment service. i.e. Bitcoin payflow notifoes you when it's pretty sure a transaction will go into a block.

[SgtSpike]

You WILL see more invalid/orphaned blocks by doing this.  More pools will find more blocks at the same time, and one or the other of them will have to be invalidated.

Also, seeing 5 confirms on a 2-minute method would equate to the same security as 1 confirm on the 10-minute method, so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?  Why not just use 1 confirmation as confirmation enough?

[ElectricMucus]

-1 for calling Litecoin a scamcoin.
-2 for the idea in general, this would further disrupt the thrust in BTC and fast confirmations aren't an issue right now, I can imagine to enable some sort of "preconfirmations" once additional hashing power is available payed for with transaction fees, this would be a way better and securer system and it could take place in about a second.

[kano]

I'd like to dispel an extremely bizarre belief that I've seen around (no I'm not saying that SgtSpike has this belief)

That is the belief that there is something special about dealing with orphan/invalid blocks by pools.

They SHOULD simply be considered as not existing once they are determined to be orphaned/invalid
(which should take way less than a single confirm and with 2 minute blocks it will be ever faster)

i.e. just continue using your pool payment calculation based on the previous valid block until you get a non-orphan block.

You can't get the generation block coins until 120 confirms (that's coded into bitcoin) so I certainly don't see any confusion about how orphan blocks should even be dealt with by pools (bizarre e.g. : BTCGuild using special payment rules and donation incentives for dealing with orphaned/invalid blocks)

[gusti]

Who needs light-speed confirmation times ? And if you REALLY need them, you already have green-addresses and the likes.
  

[kano]

-1 for calling Litecoin a scamcoin.
-2 for the idea in general, this would further disrupt the thrust in BTC and fast confirmations aren't an issue right now, I can imagine to enable some sort of "preconfirmations" once additional hashing power is available payed for with transaction fees, this would be a way better and securer system and it could take place in about a second.

Unfortunately, item -2 is how Bitcoin works - so yeah if you'd like to replace Bitcoin with some other crypto-currency that doesn't use block confirms - fine - but in this case I'm talking about Bitcoin itself, not some replacement coin

As for -1 - sorry I call all crypto-currency scam coins (yes I even came 2nd in the poll to design a logo for LTC) but the reality is that they all are either direct scams (no LTC isn't a direct scam) or they will die out given enough time.
They are useful for seeing what improvements can be made to Bitcoin, but otherwise, really not much other use at all except to take small amounts of BTC away from a lot of people (totalling a large amount of BTC) and give it to a few people.

[kano]

Who needs light-speed confirmation times ? And if you REALLY need them, you already have green-addresses and the likes.
  

Hmm - you really consider an average 10 minutes for a 5 x 2 minute confirm "light-speed" - really?

My issue is the typical 50 minute confirm - or on the previous 2 difficulties, closer to an hour.

Then of course with variance you can find some 5 block confirms in the chain taking many hours ...

Variance is of course relevant to the actual base time - in standard BTC it's base time is 10minutes.

My suggestion is to set this base time to 2minutes - divide by 5.

Now 5 is not an order of magnitude thus in related mathematical calculations (base on order of magnitude changes) represents no change

[wareen]

so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?

I think this is exactly what the OP is looking for - currently the 10 minute window is just too coarse. You have essentially 0 security for 10 minutes and afterwards a security worth thousands of dollars (the cost for somebody wanting to reverse a block with one confirmation). That might not have been an issue when difficulty was very low, but with current difficulty levels this is not very practical anymore. The more hashing power you have, the higher is the security level with 1 confirmation, but that level is already much too high for many real-world purposes.

fast confirmations aren't an issue right now

You obviously don't realize the high risk of 10 minute confirmations right now:

[DeathAndTaxes]

The need for confirms is overstated.

1) Non-finney double spend attack is very difficult to perform.  Even an instant delivery merchant can wait 60 seconds to look for second confirmation.

2) Double spend attack (not finney attack or 51% attack) is risky.  If merchant detects you then you lose your funds and merchant gains.  This is unlike virtually all other forms of conventional financial fraud where likely you are using stolen funds.   This has to reduce the propensity for even attempting double spends

3) Finney attacks require significant computational power and to justify that power would require large transaction sizes meaning that while someone could Finney attack a copy of Angry Birds for 1.5 BTC it is unlikely that will happen.

4) No form e-commerce is without fraud but the risk of a double spend is significantly less than the cost and risk of CC fraud.

Large transactions require multiple confirms but waiting an hour on large transactions isn't much of a "problem".
Small purchases are unlikely to be double spent anyways.

There are very few (if any) large instant delivery transactions that need ultra fast confirmations.

Changing block time will be difficult.  It will result in more forks and longer re-organizations.  I haven't seen anyone layout a comprehensive reason why it is worth that cost & risk.

[DeathAndTaxes]

I think this is exactly what the OP is looking for - currently the 10 minute window is just too coarse. You have essentially 0 security for 10 minutes and afterwards a security worth thousands of dollars (the cost for somebody wanting to reverse a block with one confirmation). That might not have been an issue when difficulty was very low, but with current difficulty levels this is not very practical anymore. The more hashing power you have, the higher is the security level with 1 confirmation, but that level is already much too high for many real-world purposes.

Where do you get the idea that you have essentially 0 security without a confirmation?

[ElectricMucus]

I am not proposing to replace bitcoin, but rather to improve it but also not change the essential things.
What I am proposing would be a way for receiving side transaction fees, as a bounty to do additional calculations on the transaction which are not included in the blockchain but just to secure against fraud. It wouldn't have to be much just as much so an attacker couldn't fake a transaction with a phone full of fpgas. (in case were you buy something at the counter where it really has to go fast)

[gusti]

Who needs light-speed confirmation times ? And if you REALLY need them, you already have green-addresses and the likes.
  

Hmm - you really consider an average 10 minutes for a 5 x 2 minute confirm "light-speed" - really?

Sure, specially if you compare with Visa or Mastercard chargebacks time limits of 120 days.
Anyway, whats the problem with green address technique ?

[FreeMoney]

so unless you're looking for completing a transaction with less that one confirmation worth of security (that is, one confirmation within the current 10-minute method), what's the point?

I think this is exactly what the OP is looking for - currently the 10 minute window is just too coarse. You have essentially 0 security for 10 minutes and afterwards a security worth thousands of dollars (the cost for somebody wanting to reverse a block with one confirmation). That might not have been an issue when difficulty was very low, but with current difficulty levels this is not very practical anymore. The more hashing power you have, the higher is the security level with 1 confirmation, but that level is already much too high for many real-world purposes.

fast confirmations aren't an issue right now

You obviously don't realize the high risk of 10 minute confirmations right now:

Yeah, haha, anti-social bitcoiners.

The chance that the guy you meet in starbucks to buy coins from is going to double spend on you is about the same chance that the barista flips out and murders you both. For $10k+ value tx with complete strangers you can wait an hour (or 10 min) to call it clear, or use a green address type service etc.

This is no where near worth a breaking change.

[wareen]

Where do you get the idea that you have essentially 0 security without a confirmation?

Well, maybe 0 is a bit extreme, but without relying on any out-of-band checking mechanism you cannot assess the degree of security of the transaction and this uncertainty does not change for 10 minutes.

As soon as you have 1 confirmation (no matter at which block generation rate), you have a pretty well defined degree of security.

I accept your points regarding the need for confirmations being overrated, but what about making mining for smaller pools more attractive?

[DeathAndTaxes]

I am not proposing to replace bitcoin, but rather to improve it but also not change the essential things.
What I am proposing would be a way for receiving side transaction fees, as a bounty to do additional calculations on the transaction which are not included in the blockchain but just to secure against fraud. It wouldn't have to be much just as much so an attacker couldn't fake a transaction with a phone full of fpgas. (in case were you buy something at the counter where it really has to go fast)

You can't fake a transaction.  Digital signatures prevent that.

You can only double spend it. The hashing power of the network prevents that.

A phone full of FPGA does nothing to alter either scenario.  Hell owning 10% of global hashing power doesn't alter either scenario.

[DeathAndTaxes]

Well, maybe 0 is a bit extreme, but without relying on any out-of-band checking mechanism you cannot assess the degree of security of the transaction and this uncertainty does not change for 10 minutes.

While you can't be guaranteed I think many overestimate the risk especially for small transactions.

To pull off a non-Finney double spend an attacker would need to
1) Pay merchant A with transaction A.
2) Pay merchant B with transaction B.
3) Ensure merchant A receives transaction A.
4) Ensure merchant B receives transaction B.
5) Finish both transactions

all before either transaction B is seen by merchant A or transaction A by merchant B.  That is pretty tough to do.  A merchant even waiting 60 seconds make it much tougher.  If transaction B is seen by merchant A 48 seconds later well merchant A gets to keep the money (50% chance of the money) and attacker loses.

Short blocks are a concept which sounds good so alt-coins use them to be "different" but don't really solve any significant real world issue.

I accept your points regarding the need for confirmations being overrated, but what about making mining for smaller pools more attractive?

That is a perk but not worth a hard break with compatibility of existing clients at least not IMHO.