My bad - I've been drinking coffee since 5am today. I guess it's affecting me. I meant BIP0009

This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

Apologies, I was too general in making that statement. I was referring more to the physical computing aspects, rather than the impact in the Bitcoin environment. I did read about the possibility of creating spam text to clog the validation process, and there is also the probability of miners submitting empty blocks, which does nothing to help speed up confirmations. I assume there is also the possibility of some miners including dodgy transactions to reduce their computing requirements, and the detection of these will clog up processes.

Just out of interest, why isn't BIP6 being used to determine the desirability of a 2Mb block?

Thanks for posting that. I feel I'm too junior, and don't have enough technical knowledge to justify my comments, so I'll let somebody else do it.

Actually I can see another long term advantage in reducing block generation times. As mining becomes less profitable, it will become more centralised, and because of the influence of miners, this will be bad for Bitcoin. I understand that some banks are now refusing to provide loans for mining equipment purchases because of the questionable RoI. Coin reward halving, and possible increases in energy prices will further reduce profits, and this doesn't take into account the increase in hashing difficulty because of improved hardware. With more frequent block generation, it may become possible for some nodes to become miners in a fee based system, and this will help to decentralise mining.

SegWit creates a whole range of new options, it also gives a temp. relief to the blocksize problem. Why do you need to increase blocksize without considering the optimum long term block structure? There are other options - side chains, incresing transaction density, and reducing the block creation interval are just 3 that occur to me with my limited knowledge. I am sure that there are other that more knowledgeable members can suggest.

I'm running core 0.11.2 for around 8 hours each day. I've got 8 outbound nodes and no inbound nodes. bandwidth is around 30Kb/s most times. Recently I've noticed that ping rates during synchronisation for about half of the nodes can be in excess of 500,000ms. Once I have synchronised, then all rates seem to drop below 400ms, and are often in double digits. Is this just a coincidence ( it's just an impression, I haven't kept any stats), or do some nodes try to discourage contact from nodes that are synchronising?

Maybe it is just that a high volume of received traffic distorts the ping checking.

Do you see a time when this blocktime could be reduced?

Well fees will have to increase if difficulty increases and block rewards decrease, Centralisation of mining will leave the network vulnerable to control of fees resting in a few hands. One solution would be to provide incentives to full nodes to become small solo miners.

1Mb or 2Mb - there isn't really much difference in computing terms. My view is that more 1Mb blocks is a far better solution than just taking the simplistic approach of increasing blocksize. What has come out of this whole debate in my oppinion, is the attempt by a few people to try to control Bitcoins growth and direction. For this reason alone we should resist the 2Mb immediate change. Also, as somebody has pointed out, we should switch away from large malignant companies who are trying to force changes on the philosophy of Bitcoin.

It seems to me that there are considerable long term benefits in supporting core. 2Mb blocks are a temporary attempt to solve an anticipated problem, and there would appear to be no long term benefits from its immediate implementation.

Increasing the blocksize seems to be an unsophisticated solution that will have a limited effect. I believe it will lead to an increase in centralisation as block finding rewards decrease. SegWit ands side chains should provide a short term solution, and provide a basis for future growth. This gives a breathing space whilst a solution to the current delays caused by the 10 minute block interval can be debated.

I was surprised to see a really helpful poster on that list - Shorena.

With a 150 second block interval it takes 10 minutes, and that includes 75% confirmations.

I thought the debate was about congestion. I don't see how you can reduce congestion on a busy network when the block creation interval is 10 minutes. This is regardless of the blocksizde issue.

The phoenix currency may not be an alt coin. It is a name that some people give to the world currency that will rise from the ashes of the collapsed fiat currencies. The way things are going it will probably be controlled by China and Russia through the AIIB.

Why would you want to do this?

Wouldn't it be easier just to start an alt.

Well I agree with you for a lot of transactions, but we have to realise that we are competing with big banks, and Bitcoin is being sold as a fast method of transferring money. I've got two different bank facilities that offer virtually instant transfers. If I'm buying Bitcoins for cash, then I may not want to hang around for 30 minutes for a confirmation.

With one block every 10 minutes, and then a wait for another couple of blocks to make sure it isn't orphaned. It could take around 30 minutes to confirm. Bitcoin is now up against virtually instant fiat payments, and needs faster confirmations. It doesn't need bigger blocks created at the same intervals, it needs populated blocks at shorter intervals. 2Mb blocks won't address this problem, and will probably just make it worse.

RBF is an optional feature, and it can be extremely poweful imho. This is especially true when combined with the programmable signature structure and time locking. Trying to chain transactions would be complex, as there is already a chain in place, and you would have to ensure that the attachment didn't get confirmed before the master transaction. I suspect you would also have to record block numbers, as they may not be in the same block.

Just remember that any site is on the net to make money, so whatever you do, the edge is always against you. If you want to make more Bitcoin from your coins, then you should buy something with it at a low price, sell it for fiat at a higher price, and then buy bitcoin with the proceeds.

Rinse and repeat.

I agree with that. It won't stay the only accepted crypto-currency, and it won't be the largest. With its feature rich structure, and its decentralised administration, it will remain the gold standard though.

I think there are two points in your post. I don't think that Bitcoin will stay as the largest blockchain forever ( even if you include side chains). The Phoenix currency will probably have a blockchain, and has the probability of becoming the largest, and will no doubt have a controlled central administration. I suspect that Microsoft and Google will each try to control this, and will use their cloud concepts. I doubt that the IMF or AIIB will allow them to do this.

If Bitcoin can remain on course, it has a bright future as a specialised and trusted currency, with intelligent transfer features.