Not Bitcoin XT

[nexern]

Please tell me guys this XT crap will go away and die.

I dont want to see my money evaporating because some morons that want to divide & conquer , sabotage, bitcoin.

I hope the rest of the devs and supporters figure it out that this XT will just destroy bitcoin.

Maybe XT wasn't created to help bitcoin but to destroy it? If Coinmarketcap data is correct, on 7 days bitcoin lost 15% of the value... Somebody needs to stop this fight before all the altcoins and bitcoin itself will be considered dead or with zero value!

If we reach the point with Bitcoin Core where we have small blocks that are all full, the price of bitcoin is also going to drop. At least XT has an actual, working solution for moving forward.

yes, and since it is based on a free choice, it is hard to understand the reasons to destroy an available backup.

even harder to see so much morons, trying to censor informations just to prevent consensus, probably driven
by the conviction they have to think for others.

[mmortal03]

Please tell me guys this XT crap will go away and die.

I dont want to see my money evaporating because some morons that want to divide & conquer , sabotage, bitcoin.

I hope the rest of the devs and supporters figure it out that this XT will just destroy bitcoin.

Maybe XT wasn't created to help bitcoin but to destroy it? If Coinmarketcap data is correct, on 7 days bitcoin lost 15% of the value... Somebody needs to stop this fight before all the altcoins and bitcoin itself will be considered dead or with zero value!

If we reach the point with Bitcoin Core where we have small blocks that are all full, the price of bitcoin is also going to drop. At least XT has an actual, working solution for moving forward.

Why would the price drop if the blockssize increases (or even if it becomes full).

A high velocity of money (tons of transactions) is indicative of high demand for money, thus the price increase is correlated with the transaction volume.

Bitcoin`s price has no way but to rise longterm.

Transactions wouldn't be going through, and the queue would get longer and longer. People would start going elsewhere to make payments, because the Bitcoin network would be taking too long for their transactions to confirm.

[RealBitcoin]

Please tell me guys this XT crap will go away and die.

I dont want to see my money evaporating because some morons that want to divide & conquer , sabotage, bitcoin.

I hope the rest of the devs and supporters figure it out that this XT will just destroy bitcoin.

Maybe XT wasn't created to help bitcoin but to destroy it? If Coinmarketcap data is correct, on 7 days bitcoin lost 15% of the value... Somebody needs to stop this fight before all the altcoins and bitcoin itself will be considered dead or with zero value!

If we reach the point with Bitcoin Core where we have small blocks that are all full, the price of bitcoin is also going to drop. At least XT has an actual, working solution for moving forward.

Why would the price drop if the blockssize increases (or even if it becomes full).

A high velocity of money (tons of transactions) is indicative of high demand for money, thus the price increase is correlated with the transaction volume.

Bitcoin`s price has no way but to rise longterm.

Transactions wouldn't be going through, and the queue would get longer and longer. People would start going elsewhere to make payments, because the Bitcoin network would be taking too long for their transactions to confirm.

Ok but if they raise the size then it wont, i was talking about that possibility, how it would affect the price.

This is where a good dynamic scheme, implemented in Core to the XT fork schedule, could provide a solution.

Your scenario would play out oppositely, the 8 MB chain could end up overwhelmed with all sorts of attacks, while the dynamically sized chain would scale above 8 MB to handle it.

I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

[Carlton Banks]

This is where a good dynamic scheme, implemented in Core to the XT fork schedule, could provide a solution.

Your scenario would play out oppositely, the 8 MB chain could end up overwhelmed with all sorts of attacks, while the dynamically sized chain would scale above 8 MB to handle it.

I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

Unfortunately, you're asking me to resolve an incongruity that I did not state.

I said:

8 MB vs dynamic block resizing

I did not say:

8 MB vs 1MB


If you would like to understand, please re-read the post I was replying to more carefully. I would only end up regurgitating it more or less verbatim anyway, so everything you need is there. Ask if you have specific questions regarding the details, once you have a handle on what I am actually arguing. Please don't ask me questions again before that point.

[painlord2k]

This is where a good dynamic scheme, implemented in Core to the XT fork schedule, could provide a solution.

Your scenario would play out oppositely, the 8 MB chain could end up overwhelmed with all sorts of attacks, while the dynamically sized chain would scale above 8 MB to handle it.

I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

Unfortunately, you're asking me to resolve an incongruity that I did not state.

I said:

8 MB vs dynamic block resizing

I did not say:

8 MB vs 1MB


If you would like to understand, please re-read the post I was replying to more carefully. I would only end up regurgitating it more or less verbatim anyway, so everything you need is there. Ask if you have specific questions regarding the details, once you have a handle on what I am actually arguing. Please don't ask me questions again before that point.

I do not know of any dynamic block resizing client with consensus from the miners.
When there is some code compiled and running feel free to tell us.

[painlord2k]

I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

There are many attacks possible. Some work better against the majority node and others work better if a node is in the minority.
The advantage of 8MB blocks vs. 1 MB blocks is spamming them cost 8 times more.
When the costs move from $1,000s to $10,000 or $100,000 per day, the number of possible attackers is reduced many orders of magnitude and the time they could support the attack diminished.

Just moving fees from 1/1000th of $ to 1/100th of $ or 1/10th of $ change the completely the economy and feasibility of the attack.

But someone telling just "there are a variety of attack that could" is just telling nothing.

And, anyway, antifragile is just "what do not kill me make me stronger". Let spell out these attack vectors so they can be neutralized.

[RealBitcoin]

I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

There are many attacks possible. Some work better against the majority node and others work better if a node is in the minority.
The advantage of 8MB blocks vs. 1 MB blocks is spamming them cost 8 times more.
When the costs move from $1,000s to $10,000 or $100,000 per day, the number of possible attackers is reduced many orders of magnitude and the time they could support the attack diminished.

Just moving fees from 1/1000th of $ to 1/100th of $ or 1/10th of $ change the completely the economy and feasibility of the attack.

But someone telling just "there are a variety of attack that could" is just telling nothing.

And, anyway, antifragile is just "what do not kill me make me stronger". Let spell out these attack vectors so they can be neutralized.

So you are in favor of raising the block size to 8MB, me too. It seems the most logical way to me.

If you want compressed blocks then for offchain transaction, maybe XAPO, Coinbase or Bitpay, will figure out a secure offchain BTC transfer.

The problem with XT is , that its a standalone chain, with mining and so forth, so it can fork bitcoin.

An offchain like  XAPO, Coinbase or Bitpay, is centralized, but requires no mining, so small transactions can be performed that way.


ex.  One friend sends 1 BTC to another friend, while both having Coinbase accounts, so it just transfers from 1 account to another. If the 2nd friend wants to withdraw the bitcoin, then he can, but for pointless back and forth TX, the offchain is enough.

[Carlton Banks]

I do not know of any dynamic block resizing client with consensus from the miners.
When there is some code compiled and running feel free to tell us.

I know. Do you support the concept in principle? As I said, it addresses your scenario under which the 8 MB fork is 8 times more resilient to attack.

[JorgeStolfi]

but the LN will not work, and will not be bitcoin...

Yes Jorge, that's why they're using different names for the two different technologies. Using different names for essentially different concepts is a useful method of being able to refer to said concepts in a way that makes them easy to differentiate from one another.

You got 10 Cute Points there, but surely you know what I meant? 

Blockstream's invariant message for the last two months has been "it is not necessary to increase bitcoin's block size limit because the LN will accomodate any future traffic increase."  Except that the LN will be centralized and dependent on trusted third parties; users will have to submit to AML/KYC, their coins will be locked in the system for months, ad their payments can be easily traced and blocked. Oh, and, while bitcoin exists and sort of works, the LN is very unlikely to do either thing...

[danielW]

Transactions wouldn't be going through, and the queue would get longer and longer. People would start going elsewhere to make payments, because the Bitcoin network would be taking too long for their transactions to confirm.

That wont happen because you simply have to pay a small fee for your transaction to be accepted. There will not be any queue.

Actually we are far below the limit now if you count fee paying transactions.

[JorgeStolfi]

Transactions wouldn't be going through, and the queue would get longer and longer. People would start going elsewhere to make payments, because the Bitcoin network would be taking too long for their transactions to confirm.

That wont happen because you simply have to pay a small fee for your transaction to be accepted. There will not be any queue.

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.  If there is a 60-seat bus every 10 minuets, and 100 passengers arrive at the bus stop every 10 minutes, some passengers will have to wait until the demand goes down to less than 60 per hour.   If that excess demand lasts for a few hours, many passengers will have to wait for hours.

It is grammar-school-level math.  It does not matter how much the passengers are willing to pay or how cleverly the bus company sets the fees.  

The average waiting time will depend only on the network's capacity and how the incoming traffic will vary over time.  Fiddling with the transaction priorities will not change the average delay by one second.

Actually we are far below the limit now if you count fee paying transactions.

The average daily traffic now, when there are no "stress tests", is ~120'000 transactions per day, and has grown by 5000 tx/day per month for the last 12 months.  The network's capacity, revealed by the stress tests, is ~200'000 tx/day.  Since the traffic varies during the day and with the day of the week, congestion will begin to occur well before the average demand reaches the capacity; perhaps already when the traffic will be 160'000 or 180'000 tx/day.  Even if the growth is linear rather than exponential, at the curren pace that will happen by mid-2016.  (If the growth is exponential, that may happen in early 2016.)

Most of the transactions pay the minimal fee.  True, if the minimum fees were raised to a significant level (say 0.20 USD/tx, still much less than the cost of the network), a large fraction of the traffic would disappear, and then the block size limit issue would not be urgent for another couple of years.  But neither camp seems willing to do that, for various reasons...

[canth]

On this topic, this post by DeathAndTaxes has made it to a reading on LTB.

https://bitcointalk.org/index.php?topic=946236.0 - https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-241-the-big-blockist-perspective

[Blawpaw]

I simply wish that the devs can come to an understanding and that the community opts by the Block size increase options.

[andysbizz]

No, not Bitcoin XT

[danielW]

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.

No, if the price can adjust then demand will always equal supply. What kind of professor are you?

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

[canth]

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.

No, if the price can adjust then demand will always equal supply. What kind of professor are you?

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

No, that doesn't make any sense. If 200 people want to take the bus but it only has 100 eats then it doesn't matter what the ticket price is - there will be 100 people that will be delayed getting to their destination. The only option you are talking about is that 100 people who really want to take the bus now are forced to take a taxi - aka, use something other than Bitcoin. While this is possible, it is also bad for growth when done by artificially taking seats out of the bus for the purpose of forcing ticket prices higher.

TLDR; Limiting the block size for any reason other than technical scalability reasons is a bad idea.

[danielW]

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.

No, if the price can adjust then demand will always equal supply. What kind of professor are you?

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

No, that doesn't make any sense. If 200 people want to take the bus but it only has 100 eats then it doesn't matter what the ticket price is - there will be 100 people that will be delayed getting to their destination. The only option you are talking about is that 100 people who really want to take the bus now are forced to take a taxi - aka, use something other than Bitcoin. While this is possible, it is also bad for growth when done by artificially taking seats out of the bus for the purpose of forcing ticket prices higher.

TLDR; Limiting the block size for any reason other than technical scalability reasons is a bad idea.

If the ticket price increases only 100 people will want to take the bus not 200 so there will be no queue.

Thats how economics works everywhere for everything. Using your reasoning everything on earth has a unlimited queue, from tomatoes to busses, to bitcoin now, cause if the cost to buy bitcoin (or any other product or service on earth) was lower more people would get it.

With all due respect thats absurd, thats not a queue by normal definition.

And there is nothing artificial about it, in the same way that busses can only hold so much people and there is nothing artificial about that.  

To go with the bus analogy, in my eyes you want to design a bus that holds 800 people (i.e. 8GB blocks) I find thats too much and think the design should only allow for 200 people. There is nothing artificial about a limit in the design of a bus.

Its a characteristic of Bitcoin, its no more artificial then the 21 million limit which is also just another characteristic. The second one is held more sacred tho.

[canth]

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.

No, if the price can adjust then demand will always equal supply. What kind of professor are you?

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

No, that doesn't make any sense. If 200 people want to take the bus but it only has 100 eats then it doesn't matter what the ticket price is - there will be 100 people that will be delayed getting to their destination. The only option you are talking about is that 100 people who really want to take the bus now are forced to take a taxi - aka, use something other than Bitcoin. While this is possible, it is also bad for growth when done by artificially taking seats out of the bus for the purpose of forcing ticket prices higher.

TLDR; Limiting the block size for any reason other than technical scalability reasons is a bad idea.

If the ticket price increases only 100 people will want to take the bus not 200 so there will be no queue.

Thats how economics works everywhere for everything. Using your reasoning everything on earth has a unlimited queue, from tomatoes to busses, to bitcoin now, cause if the cost to buy bitcoin (or any other product or service on earth) was lower more people would get it.

With all due respect thats absurd, thats not a queue by normal definition.

And there is nothing artificial about it, in the same way that busses can only hold so much people and there is nothing artificial about that. 

To go with the bus analogy, in my eyes you want to design a bus that holds 800 people (i.e. 8GB blocks) I find thats too much and think the design should only allow for 200 people. There is nothing artificial about a limit in the design of a bus.

Its a characteristic of Bitcoin, its no more artificial the 21 million limit which is also just another characteristic. The second one is held more sacred tho.

It's more like 200 people showed up to take the bus but when the time came to board the bus, they found out that the price was too high so they were forced to wait for the next bus. Eventually, as you say, less people are interested in taking the bus and go to another bus company. During volatile demand times, you will not know what the price is to get on the bus now - you will pay your fee and maybe if your wallet allows for you to increase the fee you'll be able to change your mind later.

Let's get one thing out of the way - the 21 million limit is completely arbitrary since any number would have worked. 1BTC would have been no different than 1 trillion BTC.

Block size is not as arbitrary since it limits the number of people that can use the system. And yes, in 20 years I think 800 person busses is something to expect. Either Bitcoin is a payment system many people use or else it's a settlement system accessible by only the super wealthy individuals or coinbase style banks. Block size needs to grow as much as it technically is possible to grow without much regard to fees, at least short term.

[danielW]

Whenever the demand is greater than the capacity, some transactions will inevitably be delayed.

No, if the price can adjust then demand will always equal supply. What kind of professor are you?

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

No, that doesn't make any sense. If 200 people want to take the bus but it only has 100 eats then it doesn't matter what the ticket price is - there will be 100 people that will be delayed getting to their destination. The only option you are talking about is that 100 people who really want to take the bus now are forced to take a taxi - aka, use something other than Bitcoin. While this is possible, it is also bad for growth when done by artificially taking seats out of the bus for the purpose of forcing ticket prices higher.

TLDR; Limiting the block size for any reason other than technical scalability reasons is a bad idea.

If the ticket price increases only 100 people will want to take the bus not 200 so there will be no queue.

Thats how economics works everywhere for everything. Using your reasoning everything on earth has a unlimited queue, from tomatoes to busses, to bitcoin now, cause if the cost to buy bitcoin (or any other product or service on earth) was lower more people would get it.

With all due respect thats absurd, thats not a queue by normal definition.

And there is nothing artificial about it, in the same way that busses can only hold so much people and there is nothing artificial about that.  

To go with the bus analogy, in my eyes you want to design a bus that holds 800 people (i.e. 8GB blocks) I find thats too much and think the design should only allow for 200 people. There is nothing artificial about a limit in the design of a bus.

Its a characteristic of Bitcoin, its no more artificial the 21 million limit which is also just another characteristic. The second one is held more sacred tho.

It's more like 200 people showed up to take the bus but when the time came to board the bus, they found out that the price was too high so they were forced to wait for the next bus. Eventually, as you

Thats why I said this

The price for fees can change, more wallets need to implement this feature tho. That is all that is needed for there to be no queues.

The more efficient the market and price finding mechanisms are the less queues there will be. Even with a small block size.

If wallets allow for the fee price to be changed, queues for average users will be rare and there will be a known amount above which users can be certain of getting into a block immediately.

If wallets additionally have smart price finding mechanism the market will be even more efficient and queues will be rarer.

If you have  replace-by-fee as Peter Todd is trying to advocate, and wallets and pools implement that functionality, the market can be even more efficient and users can have a flawless experience without having to worry about fees at all.


I believe that having some fee pressure will push wallet developers to implement these relatively simple abilities. Some small block size increase(s) will be needed tho at some point.

[RealBitcoin]

Well anyways guys, I`ll be hedging myself agains this calamity with some Litecoin and other big coins.

Whatever will happen after the september meeting of the devs, I am not taking chances, so pray that bitcoin will be ok after that.

I just dont see how the push for XT will resolve anything...