Bitcoin Core or XT? POLL

[redsn0w]

And what about this problem?

http://bitcoin.stackexchange.com/questions/8791/what-happens-to-my-bitcoins-if-theres-a-permanent-fork-in-the-chain

One of the answer :

You would be able to spend your bitcoins twice - once on each branch.

The independent branches have no way of telling whether pre-fork bitcoins have already been spent on the other branch.

This only applies to bitcoins that you received prior to the fork event. If you receive bitcoins after the fork event you have to choose one or the other.

Is that a true problem?

Yes of course, it is a problem because you will be able to spend 'your' bitcoins twice. We can assume that the supply will double (temporally) and if I will find a buyer I can sell them my coin from the both chains ( the chain-A and also in the Chain-B). When it will remain only 1 valid chain I can buy again bitcoin ( x2 of profit).

[Sampey]

When it will remain only 1 valid chain I can buy again bitcoin ( x2 of profit).

 
But if the dev team will fork his source code i don't think it will be too easy to route all "old" Btc-Qt to Btc-XT before the hard fork!

[BayAreaCoins]

Core but...

I want BTC to fork though so I can sell my 20mb BTC on y'all !

I support Gavins fork.

[1Referee]

I just voted for XT. Not a very difficult choise for me, I will follow Gavin everywhere. I don't understand why it doesn't show how much people have voted. 

[redsn0w]

I just voted for XT. Not a very difficult choise for me, I will follow Gavin everywhere. I don't understand why it doesn't show how much people have voted. 

Because if you read the first post:

Time to exercise your voting rights people

Cast your votes - ( Result to be announced after voting ends )

If your opinion changes, you can change your vote too

[jbrnt]

I voted XT because after Gavin leaves core, core devs will continue to argue on how to raise the block size limit. I think nearly all devs agree on raising the size limit, they differ on "how". Doesn't take a genius to choose between a well defined direction and a unresolved stagnation.

[xDan]

XT.

The sad thing is, if other devs provided other options they might be supported. Example: A more conservative increase to 2 MB or 5 MB, followed by further algorithmic yet still conservative increases.

I voted XT because after Gavin leaves core, core devs will continue to argue on how to raise the block size limit. I think nearly all devs agree on raising the size limit, they differ on "how". Doesn't take a genius to choose between a well defined direction and a unresolved stagnation.

+1

[cellard]

I think XT could be used some sort of lab test where they test stuff out, and if it works out well, they they add it to the current "official" Bitcoin. Doesn't this make sense?

I would love a Satoshi comeback to drop some common sense in this times of crucial decision taking and confusion.

[johnyj]

I don't see any statistics of XT nodes on this picture, most of the nodes are running 0.9.x -0.10.x

https://getaddr.bitnodes.io/dashboard/#user-agents

[AgentofCoin]

I vote for and push for an agreement reached between the devs.
Maybe a middle ground can exist here.

I do not think this is good for Bitcoin/bitcoin.
Nothing good will come from this.
We may all become the losers in this game of chicken.

I vote for a settlement!

Edit: I will not vote in this poll. I choose the middle ground.

[solex]

My Q&A on why going with XT is the correct and conservative approach if Core fails to upgrade with Gavin's fix to the 1MB problem:
----------------------------------------------------------------------------------------------------------------------------------------------------------------

Q; What is a conservative course of action?
A: Conservative action (for a successful enterprise) is always to maintain the status quo as much as possible in the face of necessary change. Because Bitcoin has prospered for 6 years the status quo is to maintain the network as it is now.
Unfortunately, neither keeping the 1MB or increasing it can maintain the network how it is now!
This is a dilemma, but all enterprises face dilemmas at some time: necessity for change from competition, customers, technology or regulation. So, a conservative position is to adapt to an external change while maintaining the status quo as much as possible.

Q; Why isn’t “doing nothing” the best approach?
A: Because “doing nothing” has no real fall-back plan.
The fall-back plan for an increase to, say 20MB, is a later soft-fork down to 2 or 3MB. This may or may not become necessary, but at least it can be achieved smoothly. Think: duck paddling hard in a millpond.
If the 1MB limit is kept and causes mayhem to confirmation times, bad publicity etc, then the fall-back “plan” is a painful and panicked hard-fork. Think: duck going through the water-wheel.

Q: When is a hard-fork not a hard-fork?
A: When it is planned so long ahead that 100% of all software instances are upgraded before it takes effect.
In practice, this can’t be achieved but targeting 90+% is desirable and sufficient for a smooth transition.

Q: When is a hard-fork most painful?
A: When it is a rapid decision, forced by circumstances, and everyone has to upgrade in a very short time.
The more delay before acting causes a bigger downside when a fork becomes forced.

Q: What about keeping the 1MB to put upward pressure on fees?
A: That is “Blockchain Economics”. Applying to the blockchain a false economic model of reality, i.e. an economic model which has a hard limit such as the zero-bound in Central Bank interest rate targeting which attempts to set the price of money in a fiat system, but fails in a deflationary economy.
When the rubber hits the road of this reality the result will be a rapid plateau in total fees and then an inexorable decline as users abandon the use of Bitcoin in favour of alternatives, and new cryptocurrency users keen on the future of money are forced to use alternatives from the get-go.

Q: OK, but I’m a determined fan of Blockchain Economics. When is it safe to try it?
A: It’s never safe because of the Trade-Off, but the best time is trying a soft-limit while the hard-limit is higher (safety valve), and when the network is small but viable, and no one is paying attention, such as the situation in 2012, Unfortunately, the time for this has gone because the Bitcoin market capitalisation is in the billions of dollars and the world’s press is closely watching.

Q: What is the Trade-Off?
A: A fundamental of Bitcoin is its confirmation cycle which averages 10 minutes.
When blocks have extra space the transaction counts per block are highly variable, but any given unconfirmed  transaction may expect confirmation in 10 minutes.  
When blocks are full transaction counts per block are stable, but the expected confirmation time for a unconfirmed transaction becomes highly variable.

Q: Is the benefit of very stable block sizes worth the cost of highly variable confirmation times?
A: No!

Q; When is a flooding or spamming attack on Bitcoin most effective and cheapest to execute?
A: When blocks are nearly always full. It is least effective and most expensive when blocks normally have lots of unused space.

Q: Can Bitcoin be a reserve / settlement currency with high-value users, primarily a store of value like an electronic gold?
A: Yes, but not when it can only handle 0.01% (a ten-thousandth) of the world’s transactions. Not when another cryptocurrency is handling even 1%, let alone 10%, 50% or 99.99% of the world’s transactions. Bitcoin can only become a true reserve currency and electronic gold when it scales. Otherwise this remains a dream, a mirage.

Q: What about bandwidth considerations?
A: Satoshi put the 1MB in place when there were no lightweight nodes and all users had to run a full node. That time is nearly five years ago. Global improvements in bandwidth mean that the overhead he allowed for, by selecting 1MB in 2010, is more like 4MB in 2015.

Q: What about technical concerns such as growth of the UTXO set?
A: The smartest way to meet a challenge is to leverage it as an opportunity.
Example : Aligning the demand for blocks larger than 1MB with an incentive to maintain a cleaner UTXO set.
The complexity of this change needs to be weighed against the simplicity of a fixed limit (e.g. 20MB). Sometimes simplicity outweighs a leveraged gain.
Also, the UTXO set could be kept cleaner, as a stand-alone change: allowing free transaction space based upon reducing utxo (negative delta) instead of being based upon the number of days destroyed, which was to encourage old coins being spent, something less important.

Q. What are the implications for decentralisation, particularly: full node counts?
A. Full node counts have been in decline for several years, mostly because of the growth in SPV wallets and lightweight nodes, and mining pools (for minimizing variance), also the increase in blockchain size for users who won’t spend a few $100 on TB disks.
Many node owners are long-term investors and believers in Bitcoin as a major currency and payment system of the future. That is why they hang in there. They are waiting to see it scale and will run non-mining, non-commercial nodes to do it. If the status quo is destabilized (e.g. unstable confirmation times) then full node owners will switch off faster.
Full node counts would be improved by greater adoption and the future use of node payment services where non-mining nodes get micro-payments via off-chain channels for servicing the network.
Keeping the 1MB, because it is the least conservative action, will accelerate the decline in full node counts.

Q: What if someone makes a load of gigablocks?
A: They can’t. If the 1MB disappeared, the message size limit of about 32MB means that this is the maximum block size. Gigablocks are not possible until all nodes support set reconciliation ("bandwidth reduction scheme") such as in IBLT, and block segmentation software.

Q: Why not wait for off-chain solutions which can handle 100x the on-chain volume, like Lightning Networks?
A: There is no time for that, LN is still in the documentation and technical specification stages, also the LN opinion is that 1MB is too small for them in the event that a lot of payment channels need to be closed quickly. 32MB or even 20MB would be sufficient for a long time.

[ArticMine]

I voted for XT. I really do not see keeping the 1MB blocksize limit as a viable option for Bitcoin. Furthermore I have felt this way for a very long time. I invite anyone to look at my posts on the subject.

[Newar]

I don't see any statistics of XT nodes on this picture, most of the nodes are running 0.9.x -0.10.x

https://getaddr.bitnodes.io/dashboard/#user-agents

It will take time:
https://getaddr.bitnodes.io/nodes/?q=/Bitcoin%20XT:0.10.0/
https://getaddr.bitnodes.io/nodes/?q=/Bitcoin%20XT:0.10.1/

15 at the moment.

[MicroGuy]

Satoshi picked Gavin to succeed him for a reason. It's not like he picked some random guy from the forum. Why should we now question Satoshi at this late date? The inventor intended for that selection to mean something.

I feel like the best thing to do is let Gavin make the changes as "HE sees fit" and then celebrate with a beer or two!

[Light]

I personally believe that XT is probably the way to go - I can't see a clear reason why we shouldn't raise the limit now and avoid this issue becoming bigger in the future. We'll be in more trouble if we come to the point where transactions take hours to confirm and have to rush out an update to deal with it.

[jehst]

XT. Upgrade or die.

[dunkbc]

So XT 0.10.1 has the larger block size implementation ?
It does not say so on the github page.

[achow101]

So XT 0.10.1 has the larger block size implementation ?
It does not say so on the github page.

I don't think it has it yet. However, Gavin is going to leave Bitcoin core development and implement the larger blocks into XT if the core devs cannot agree. At least, that's what it sounds like in the email.

[Pecunia non olet]

and Satoshi hand-picked Gavin.

Is there actually any evidence for that? Where?

[BayAreaCoins]

Silly XT altcoiners