-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.
Topic: Suggested MAJOR change to Bitcoin - page 6. (Read 9442 times)
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Jump to: